Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xdp: Remove WARN() from __xdp_reg_mem_model()<br /> <br /> syzkaller reports a warning in __xdp_reg_mem_model().<br /> <br /> The warning occurs only if __mem_id_init_hash_table() returns an error. It<br /> returns the error in two cases:<br /> <br /> 1. memory allocation fails;<br /> 2. rhashtable_init() fails when some fields of rhashtable_params<br /> struct are not initialized properly.<br /> <br /> The second case cannot happen since there is a static const rhashtable_params<br /> struct with valid fields. So, warning is only triggered when there is a<br /> problem with memory allocation.<br /> <br /> Thus, there is no sense in using WARN() to handle this error and it can be<br /> safely removed.<br /> <br /> WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299<br /> <br /> CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024<br /> RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299<br /> <br /> Call Trace:<br /> xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344<br /> xdp_test_run_setup net/bpf/test_run.c:188 [inline]<br /> bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377<br /> bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267<br /> bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240<br /> __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649<br /> __do_sys_bpf kernel/bpf/syscall.c:5738 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5736 [inline]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736<br /> do_syscall_64+0xfb/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Fix NULL pointer dereference in gfs2_log_flush<br /> <br /> In gfs2_jindex_free(), set sdp-&gt;sd_jdesc to NULL under the log flush<br /> lock to provide exclusion against gfs2_log_flush().<br /> <br /> In gfs2_log_flush(), check if sdp-&gt;sd_jdesc is non-NULL before<br /> dereferencing it. Otherwise, we could run into a NULL pointer<br /> dereference when outstanding glock work races with an unmount<br /> (glock_work_func -&gt; run_queue -&gt; do_xmote -&gt; inode_go_sync -&gt;<br /> gfs2_log_flush).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Skip pipe if the pipe idx not set properly<br /> <br /> [why]<br /> Driver crashes when pipe idx not set properly<br /> <br /> [how]<br /> Add code to skip the pipe that idx not set properly

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Add a NULL check in xe_ttm_stolen_mgr_init<br /> <br /> Add an explicit check to ensure that the mgr is not NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix potential integer overflow in page size calculation<br /> <br /> Explicitly cast tbo-&gt;page_alignment to u64 before bit-shifting to<br /> prevent overflow when assigning to min_page_size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()<br /> <br /> set_memory_rox() can fail, leaving memory unprotected.<br /> <br /> Check return and bail out when bpf_jit_binary_lock_ro() returns<br /> an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ionic: use dev_consume_skb_any outside of napi<br /> <br /> If we&amp;#39;re not in a NAPI softirq context, we need to be careful<br /> about how we call napi_consume_skb(), specifically we need to<br /> call it with budget==0 to signal to it that we&amp;#39;re not in a<br /> safe context.<br /> <br /> This was found while running some configuration stress testing<br /> of traffic and a change queue config loop running, and this<br /> curious note popped out:<br /> <br /> [ 4371.402645] BUG: using smp_processor_id() in preemptible [00000000] code: ethtool/20545<br /> [ 4371.402897] caller is napi_skb_cache_put+0x16/0x80<br /> [ 4371.403120] CPU: 25 PID: 20545 Comm: ethtool Kdump: loaded Tainted: G OE 6.10.0-rc3-netnext+ #8<br /> [ 4371.403302] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 01/23/2021<br /> [ 4371.403460] Call Trace:<br /> [ 4371.403613] <br /> [ 4371.403758] dump_stack_lvl+0x4f/0x70<br /> [ 4371.403904] check_preemption_disabled+0xc1/0xe0<br /> [ 4371.404051] napi_skb_cache_put+0x16/0x80<br /> [ 4371.404199] ionic_tx_clean+0x18a/0x240 [ionic]<br /> [ 4371.404354] ionic_tx_cq_service+0xc4/0x200 [ionic]<br /> [ 4371.404505] ionic_tx_flush+0x15/0x70 [ionic]<br /> [ 4371.404653] ? ionic_lif_qcq_deinit.isra.23+0x5b/0x70 [ionic]<br /> [ 4371.404805] ionic_txrx_deinit+0x71/0x190 [ionic]<br /> [ 4371.404956] ionic_reconfigure_queues+0x5f5/0xff0 [ionic]<br /> [ 4371.405111] ionic_set_ringparam+0x2e8/0x3e0 [ionic]<br /> [ 4371.405265] ethnl_set_rings+0x1f1/0x300<br /> [ 4371.405418] ethnl_default_set_doit+0xbb/0x160<br /> [ 4371.405571] genl_family_rcv_msg_doit+0xff/0x130<br /> [...]<br /> <br /> I found that ionic_tx_clean() calls napi_consume_skb() which calls<br /> napi_skb_cache_put(), but before that last call is the note<br /> /* Zero budget indicate non-NAPI context called us, like netpoll */<br /> and<br /> DEBUG_NET_WARN_ON_ONCE(!in_softirq());<br /> <br /> Those are pretty big hints that we&amp;#39;re doing it wrong. We can pass a<br /> context hint down through the calls to let ionic_tx_clean() know what<br /> we&amp;#39;re doing so it can call napi_consume_skb() correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix may_goto with negative offset.<br /> <br /> Zac&amp;#39;s syzbot crafted a bpf prog that exposed two bugs in may_goto.<br /> The 1st bug is the way may_goto is patched. When offset is negative<br /> it should be patched differently.<br /> The 2nd bug is in the verifier:<br /> when current state may_goto_depth is equal to visited state may_goto_depth<br /> it means there is an actual infinite loop. It&amp;#39;s not correct to prune<br /> exploration of the program at this point.<br /> Note, that this check doesn&amp;#39;t limit the program to only one may_goto insn,<br /> since 2nd and any further may_goto will increment may_goto_depth only<br /> in the queued state pushed for future exploration. The current state<br /> will have may_goto_depth == 0 regardless of number of may_goto insns<br /> and the verifier has to explore the program until bpf_exit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd: acp: add a null check for chip_pdev structure<br /> <br /> When acp platform device creation is skipped, chip-&gt;chip_pdev value will<br /> remain NULL. Add NULL check for chip-&gt;chip_pdev structure in<br /> snd_acp_resume() function to avoid null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix remap of arena.<br /> <br /> The bpf arena logic didn&amp;#39;t account for mremap operation. Add a refcnt for<br /> multiple mmap events to prevent use-after-free in arena_vm_close.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix possible double free in error handling path<br /> <br /> When auxiliary_device_add() returns error and then calls<br /> auxiliary_device_uninit(), callback function adev_release<br /> calls kfree(madev). We shouldn&amp;#39;t call kfree(madev) again<br /> in the error handling path. Set &amp;#39;madev&amp;#39; to NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode<br /> <br /> syzbot reported uninit memory usages during map_{lookup,delete}_elem.<br /> <br /> ==========<br /> BUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline]<br /> BUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796<br /> __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline]<br /> dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796<br /> ____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline]<br /> bpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38<br /> ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997<br /> __bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237<br /> ==========<br /> <br /> The reproducer should be in the interpreter mode.<br /> <br /> The C reproducer is trying to run the following bpf prog:<br /> <br /> 0: (18) r0 = 0x0<br /> 2: (18) r1 = map[id:49]<br /> 4: (b7) r8 = 16777216<br /> 5: (7b) *(u64 *)(r10 -8) = r8<br /> 6: (bf) r2 = r10<br /> 7: (07) r2 += -229<br /> ^^^^^^^^^^<br /> <br /> 8: (b7) r3 = 8<br /> 9: (b7) r4 = 0<br /> 10: (85) call dev_map_lookup_elem#1543472<br /> 11: (95) exit<br /> <br /> It is due to the "void *key" (r2) passed to the helper. bpf allows uninit<br /> stack memory access for bpf prog with the right privileges. This patch<br /> uses kmsan_unpoison_memory() to mark the stack as initialized.<br /> <br /> This should address different syzbot reports on the uninit "void *key"<br /> argument during map_{lookup,delete}_elem.