Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()<br /> <br /> If the allocation in msm_disp_state_dump_regs() failed then<br /> `block-&gt;state` can be NULL. The msm_disp_state_print_regs() function<br /> _does_ have code to try to handle it with:<br /> <br /> if (*reg)<br /> dump_addr = *reg;<br /> <br /> ...but since "dump_addr" is initialized to NULL the above is actually<br /> a noop. The code then goes on to dereference `dump_addr`.<br /> <br /> Make the function print "Registers not stored" when it sees a NULL to<br /> solve this. Since we&amp;#39;re touching the code, fix<br /> msm_disp_state_print_regs() not to pointlessly take a double-pointer<br /> and properly mark the pointer as `const`.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/619657/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda/cs8409: Fix possible NULL dereference<br /> <br /> If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then<br /> NULL pointer dereference will occur in the next line.<br /> <br /> Since dolphin_fixups function is a hda_fixup function which is not supposed<br /> to return any errors, add simple check before dereference, ignore the fail.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: devmap: provide rxq after redirect<br /> <br /> rxq contains a pointer to the device from where<br /> the redirect happened. Currently, the BPF program<br /> that was executed after a redirect via BPF_MAP_TYPE_DEVMAP*<br /> does not have it set.<br /> <br /> This is particularly bad since accessing ingress_ifindex, e.g.<br /> <br /> SEC("xdp")<br /> int prog(struct xdp_md *pkt)<br /> {<br /> return bpf_redirect_map(&amp;dev_redirect_map, 0, 0);<br /> }<br /> <br /> SEC("xdp/devmap")<br /> int prog_after_redirect(struct xdp_md *pkt)<br /> {<br /> bpf_printk("ifindex %i", pkt-&gt;ingress_ifindex);<br /> return XDP_PASS;<br /> }<br /> <br /> depends on access to rxq, so a NULL pointer gets dereferenced:<br /> <br /> [ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 574.475188] #PF: supervisor read access in kernel mode<br /> [ 574.475194] #PF: error_code(0x0000) - not-present page<br /> [ 574.475199] PGD 0 P4D 0<br /> [ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23<br /> [ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023<br /> [ 574.475231] Workqueue: mld mld_ifc_work<br /> [ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<br /> [ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b<br /> [ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206<br /> [ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000<br /> [ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0<br /> [ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001<br /> [ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000<br /> [ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000<br /> [ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000<br /> [ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0<br /> [ 574.475303] PKRU: 55555554<br /> [ 574.475306] Call Trace:<br /> [ 574.475313] <br /> [ 574.475318] ? __die+0x23/0x70<br /> [ 574.475329] ? page_fault_oops+0x180/0x4c0<br /> [ 574.475339] ? skb_pp_cow_data+0x34c/0x490<br /> [ 574.475346] ? kmem_cache_free+0x257/0x280<br /> [ 574.475357] ? exc_page_fault+0x67/0x150<br /> [ 574.475368] ? asm_exc_page_fault+0x26/0x30<br /> [ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<br /> [ 574.475386] bq_xmit_all+0x158/0x420<br /> [ 574.475397] __dev_flush+0x30/0x90<br /> [ 574.475407] veth_poll+0x216/0x250 [veth]<br /> [ 574.475421] __napi_poll+0x28/0x1c0<br /> [ 574.475430] net_rx_action+0x32d/0x3a0<br /> [ 574.475441] handle_softirqs+0xcb/0x2c0<br /> [ 574.475451] do_softirq+0x40/0x60<br /> [ 574.475458] <br /> [ 574.475461] <br /> [ 574.475464] __local_bh_enable_ip+0x66/0x70<br /> [ 574.475471] __dev_queue_xmit+0x268/0xe40<br /> [ 574.475480] ? selinux_ip_postroute+0x213/0x420<br /> [ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0<br /> [ 574.475502] ip6_finish_output2+0x2be/0x640<br /> [ 574.475512] ? nf_hook_slow+0x42/0xf0<br /> [ 574.475521] ip6_finish_output+0x194/0x300<br /> [ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10<br /> [ 574.475538] mld_sendpack+0x17c/0x240<br /> [ 574.475548] mld_ifc_work+0x192/0x410<br /> [ 574.475557] process_one_work+0x15d/0x380<br /> [ 574.475566] worker_thread+0x29d/0x3a0<br /> [ 574.475573] ? __pfx_worker_thread+0x10/0x10<br /> [ 574.475580] ? __pfx_worker_thread+0x10/0x10<br /> [ 574.475587] kthread+0xcd/0x100<br /> [ 574.475597] ? __pfx_kthread+0x10/0x10<br /> [ 574.475606] ret_from_fork+0x31/0x50<br /> [ 574.475615] ? __pfx_kthread+0x10/0x10<br /> [ 574.475623] ret_from_fork_asm+0x1a/0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Make sure internal and UAPI bpf_redirect flags don&amp;#39;t overlap<br /> <br /> The bpf_redirect_info is shared between the SKB and XDP redirect paths,<br /> and the two paths use the same numeric flag values in the ri-&gt;flags<br /> field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that<br /> if skb bpf_redirect_neigh() is used with a non-NULL params argument and,<br /> subsequently, an XDP redirect is performed using the same<br /> bpf_redirect_info struct, the XDP path will get confused and end up<br /> crashing, which syzbot managed to trigger.<br /> <br /> With the stack-allocated bpf_redirect_info, the structure is no longer<br /> shared between the SKB and XDP paths, so the crash doesn&amp;#39;t happen<br /> anymore. However, different code paths using identically-numbered flag<br /> values in the same struct field still seems like a bit of a mess, so<br /> this patch cleans that up by moving the flag definitions together and<br /> redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap<br /> with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make<br /> sure the overlap is not re-introduced by mistake.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> be2net: fix potential memory leak in be_xmit()<br /> <br /> The be_xmit() returns NETDEV_TX_OK without freeing skb<br /> in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()<br /> <br /> The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb<br /> in case of skb-&gt;len being too long, add dev_kfree_skb() to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: fix unbalanced rpm put() with fence_fini()<br /> <br /> Currently we can call fence_fini() twice if something goes wrong when<br /> sending the GuC CT for the tlb request, since we signal the fence and<br /> return an error, leading to the caller also calling fini() on the error<br /> path in the case of stack version of the flow, which leads to an extra<br /> rpm put() which might later cause device to enter suspend when it<br /> shouldn&amp;#39;t. It looks like we can just drop the fini() call since the<br /> fence signaller side will already call this for us.<br /> <br /> There are known mysterious splats with device going to sleep even with<br /> an rpm ref, and this could be one candidate.<br /> <br /> v2 (Matt B):<br /> - Prefer warning if we detect double fini()<br /> <br /> (cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Don&amp;#39;t free job in TDR<br /> <br /> Freeing job in TDR is not safe as TDR can pass the run_job thread<br /> resulting in UAF. It is only safe for free job to naturally be called by<br /> the scheduler. Rather free job in TDR, add to pending list.<br /> <br /> (cherry picked from commit ea2f6a77d0c40d97f4a4dc93fee4afe15d94926d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix possible double free in smb2_set_ea()<br /> <br /> Clang static checker(scan-build) warning：<br /> fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory.<br /> 1304 | kfree(ea);<br /> | ^~~~~~~~~<br /> <br /> There is a double free in such case:<br /> &amp;#39;ea is initialized to NULL&amp;#39; -&gt; &amp;#39;first successful memory allocation for<br /> ea&amp;#39; -&gt; &amp;#39;something failed, goto sea_exit&amp;#39; -&gt; &amp;#39;first memory release for ea&amp;#39;<br /> -&gt; &amp;#39;goto replay_again&amp;#39; -&gt; &amp;#39;second goto sea_exit before allocate memory<br /> for ea&amp;#39; -&gt; &amp;#39;second memory release for ea resulted in double free&amp;#39;.<br /> <br /> Re-initialie &amp;#39;ea&amp;#39; to NULL near to the replay_again label, it can fix this<br /> double free problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Don&amp;#39;t call cleanup on profile rollback failure<br /> <br /> When profile rollback fails in mlx5e_netdev_change_profile, the netdev<br /> profile var is left set to NULL. Avoid a crash when unloading the driver<br /> by not calling profile-&gt;cleanup in such a case.<br /> <br /> This was encountered while testing, with the original trigger that<br /> the wq rescuer thread creation got interrupted (presumably due to<br /> Ctrl+C-ing modprobe), which gets converted to ENOMEM (-12) by<br /> mlx5e_priv_init, the profile rollback also fails for the same reason<br /> (signal still active) so the profile is left as NULL, leading to a crash<br /> later in _mlx5e_remove.<br /> <br /> [ 732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2)<br /> [ 734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> [ 734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12<br /> [ 734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12<br /> [ 734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> [ 734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12<br /> [ 734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12<br /> [ 745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [ 745.538222] #PF: supervisor read access in kernel mode<br /> <br /> [ 745.551290] Call Trace:<br /> [ 745.551590] <br /> [ 745.551866] ? __die+0x20/0x60<br /> [ 745.552218] ? page_fault_oops+0x150/0x400<br /> [ 745.555307] ? exc_page_fault+0x79/0x240<br /> [ 745.555729] ? asm_exc_page_fault+0x22/0x30<br /> [ 745.556166] ? mlx5e_remove+0x6b/0xb0 [mlx5_core]<br /> [ 745.556698] auxiliary_bus_remove+0x18/0x30<br /> [ 745.557134] device_release_driver_internal+0x1df/0x240<br /> [ 745.557654] bus_remove_device+0xd7/0x140<br /> [ 745.558075] device_del+0x15b/0x3c0<br /> [ 745.558456] mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core]<br /> [ 745.559112] mlx5_unregister_device+0x34/0x50 [mlx5_core]<br /> [ 745.559686] mlx5_uninit_one+0x46/0xf0 [mlx5_core]<br /> [ 745.560203] remove_one+0x4e/0xd0 [mlx5_core]<br /> [ 745.560694] pci_device_remove+0x39/0xa0<br /> [ 745.561112] device_release_driver_internal+0x1df/0x240<br /> [ 745.561631] driver_detach+0x47/0x90<br /> [ 745.562022] bus_remove_driver+0x84/0x100<br /> [ 745.562444] pci_unregister_driver+0x3b/0x90<br /> [ 745.562890] mlx5_cleanup+0xc/0x1b [mlx5_core]<br /> [ 745.563415] __x64_sys_delete_module+0x14d/0x2f0<br /> [ 745.563886] ? kmem_cache_free+0x1b0/0x460<br /> [ 745.564313] ? lockdep_hardirqs_on_prepare+0xe2/0x190<br /> [ 745.564825] do_syscall_64+0x6d/0x140<br /> [ 745.565223] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [ 745.565725] RIP: 0033:0x7f1579b1288b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context<br /> <br /> PRMT needs to find the correct type of block to translate the PA-VA<br /> mapping for EFI runtime services.<br /> <br /> The issue arises because the PRMT is finding a block of type<br /> EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services<br /> as described in Section 2.2.2 (Runtime Services) of the UEFI<br /> Specification [1]. Since the PRM handler is a type of runtime service,<br /> this causes an exception when the PRM handler is called.<br /> <br /> [Firmware Bug]: Unable to handle paging request in EFI runtime service<br /> WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341<br /> __efi_queue_work+0x11c/0x170<br /> Call trace:<br /> <br /> Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM<br /> context.<br /> <br /> If no suitable block is found, a warning message will be printed, but<br /> the procedure continues to manage the next PRM handler.<br /> <br /> However, if the PRM handler is actually called without proper allocation,<br /> it would result in a failure during error handling.<br /> <br /> By using the correct memory types for runtime services, ensure that the<br /> PRM handler and the context are properly mapped in the virtual address<br /> space during runtime, preventing the paging request error.<br /> <br /> The issue is really that only memory that has been remapped for runtime<br /> by the firmware can be used by the PRM handler, and so the region needs<br /> to have the EFI_MEMORY_RUNTIME attribute.<br /> <br /> [ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: validate new SA&amp;#39;s prefixlen using SA family when sel.family is unset<br /> <br /> This expands the validation introduced in commit 07bf7908950a ("xfrm:<br /> Validate address prefix lengths in the xfrm selector.")<br /> <br /> syzbot created an SA with<br /> usersa.sel.family = AF_UNSPEC<br /> usersa.sel.prefixlen_s = 128<br /> usersa.family = AF_INET<br /> <br /> Because of the AF_UNSPEC selector, verify_newsa_info doesn&amp;#39;t put<br /> limits on prefixlen_{s,d}. But then copy_from_user_state sets<br /> x-&gt;sel.family to usersa.family (AF_INET). Do the same conversion in<br /> verify_newsa_info before validating prefixlen_{s,d}, since that&amp;#39;s how<br /> prefixlen is going to be used later on.