Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsl/fman: Fix refcount handling of fman-related devices<br /> <br /> In mac_probe() there are multiple calls to of_find_device_by_node(),<br /> fman_bind() and fman_port_bind() which takes references to of_dev-&gt;dev.<br /> Not all references taken by these calls are released later on error path<br /> in mac_probe() and in mac_remove() which lead to reference leaks.<br /> <br /> Add references release.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix overloading of MEM_UNINIT&amp;#39;s meaning<br /> <br /> Lonial reported an issue in the BPF verifier where check_mem_size_reg()<br /> has the following code:<br /> <br /> if (!tnum_is_const(reg-&gt;var_off))<br /> /* For unprivileged variable accesses, disable raw<br /> * mode so that the program is required to<br /> * initialize all the memory that the helper could<br /> * just partially fill up.<br /> */<br /> meta = NULL;<br /> <br /> This means that writes are not checked when the register containing the<br /> size of the passed buffer has not a fixed size. Through this bug, a BPF<br /> program can write to a map which is marked as read-only, for example,<br /> .rodata global maps.<br /> <br /> The problem is that MEM_UNINIT&amp;#39;s initial meaning that "the passed buffer<br /> to the BPF helper does not need to be initialized" which was added back<br /> in commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type")<br /> got overloaded over time with "the passed buffer is being written to".<br /> <br /> The problem however is that checks such as the above which were added later<br /> via 06c1c049721a ("bpf: allow helpers access to variable memory") set meta<br /> to NULL in order force the user to always initialize the passed buffer to<br /> the helper. Due to the current double meaning of MEM_UNINIT, this bypasses<br /> verifier write checks to the memory (not boundary checks though) and only<br /> assumes the latter memory is read instead.<br /> <br /> Fix this by reverting MEM_UNINIT back to its original meaning, and having<br /> MEM_WRITE as an annotation to BPF helpers in order to then trigger the<br /> BPF verifier checks for writing to memory.<br /> <br /> Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO}<br /> we can access fn-&gt;arg_type[arg - 1] since it must contain a preceding<br /> ARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removed<br /> altogether since we do check both BPF_READ and BPF_WRITE. Same for the<br /> equivalent check_kfunc_mem_size_reg().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: use cond_resched() in nsim_dev_trap_report_work()<br /> <br /> I am still seeing many syzbot reports hinting that syzbot<br /> might fool nsim_dev_trap_report_work() with hundreds of ports [1]<br /> <br /> Lets use cond_resched(), and system_unbound_wq<br /> instead of implicit system_wq.<br /> <br /> [1]<br /> INFO: task syz-executor:20633 blocked for more than 143 seconds.<br /> Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz-executor state:D stack:25856 pid:20633 tgid:20633 ppid:1 flags:0x00004006<br /> ...<br /> NMI backtrace for cpu 1<br /> CPU: 1 UID: 0 PID: 16760 Comm: kworker/1:0 Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: events nsim_dev_trap_report_work<br /> RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:210<br /> Code: 89 fb e8 23 00 00 00 48 8b 3d 04 fb 9c 0c 48 89 de 5b e9 c3 c7 5d 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1e fa 48 8b 04 24 65 48 8b 0c 25 c0 d7 03 00 65 8b 15 60 f0<br /> RSP: 0018:ffffc90000a187e8 EFLAGS: 00000246<br /> RAX: 0000000000000100 RBX: ffffc90000a188e0 RCX: ffff888027d3bc00<br /> RDX: ffff888027d3bc00 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffff88804a2e6000 R08: ffffffff8a4bc495 R09: ffffffff89da3577<br /> R10: 0000000000000004 R11: ffffffff8a4bc2b0 R12: dffffc0000000000<br /> R13: ffff88806573b503 R14: dffffc0000000000 R15: ffff8880663cca00<br /> FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc90a747f98 CR3: 000000000e734000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 000000000000002b DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> <br /> <br /> __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382<br /> spin_unlock_bh include/linux/spinlock.h:396 [inline]<br /> nsim_dev_trap_report drivers/net/netdevsim/dev.c:820 [inline]<br /> nsim_dev_trap_report_work+0x75d/0xaa0 drivers/net/netdevsim/dev.c:850<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3391<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br />

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.