Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ionic: fix kernel panic due to multi-buffer handling<br /> <br /> Currently, the ionic_run_xdp() doesn&amp;#39;t handle multi-buffer packets<br /> properly for XDP_TX and XDP_REDIRECT.<br /> When a jumbo frame is received, the ionic_run_xdp() first makes xdp<br /> frame with all necessary pages in the rx descriptor.<br /> And if the action is either XDP_TX or XDP_REDIRECT, it should unmap<br /> dma-mapping and reset page pointer to NULL for all pages, not only the<br /> first page.<br /> But it doesn&amp;#39;t for SG pages. So, SG pages unexpectedly will be reused.<br /> It eventually causes kernel panic.<br /> <br /> Oops: general protection fault, probably for non-canonical address 0x504f4e4dbebc64ff: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.10.0-rc3+ #25<br /> RIP: 0010:xdp_return_frame+0x42/0x90<br /> Code: 01 75 12 5b 4c 89 e6 5d 31 c9 41 5c 31 d2 41 5d e9 73 fd ff ff 44 8b 6b 20 0f b7 43 0a 49 81 ed 68 01 00 00 49 29 c5 49 01 fd 80 7d0<br /> RSP: 0018:ffff99d00122ce08 EFLAGS: 00010202<br /> RAX: 0000000000005453 RBX: ffff8d325f904000 RCX: 0000000000000001<br /> RDX: 00000000670e1000 RSI: 000000011f90d000 RDI: 504f4e4d4c4b4a49<br /> RBP: ffff99d003907740 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 000000011f90d000 R11: 0000000000000000 R12: ffff8d325f904010<br /> R13: 504f4e4dbebc64fd R14: ffff8d3242b070c8 R15: ffff99d0039077c0<br /> FS: 0000000000000000(0000) GS:ffff8d399f780000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f41f6c85e38 CR3: 000000037ac30000 CR4: 00000000007506f0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? die_addr+0x33/0x90<br /> ? exc_general_protection+0x251/0x2f0<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? xdp_return_frame+0x42/0x90<br /> ionic_tx_clean+0x211/0x280 [ionic 15881354510e6a9c655c59c54812b319ed2cd015]<br /> ionic_tx_cq_service+0xd3/0x210 [ionic 15881354510e6a9c655c59c54812b319ed2cd015]<br /> ionic_txrx_napi+0x41/0x1b0 [ionic 15881354510e6a9c655c59c54812b319ed2cd015]<br /> __napi_poll.constprop.0+0x29/0x1b0<br /> net_rx_action+0x2c4/0x350<br /> handle_softirqs+0xf4/0x320<br /> irq_exit_rcu+0x78/0xa0<br /> common_interrupt+0x77/0x90

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: initialise nfsd_info.mutex early.<br /> <br /> nfsd_info.mutex can be dereferenced by svc_pool_stats_start()<br /> immediately after the new netns is created. Currently this can<br /> trigger an oops.<br /> <br /> Move the initialisation earlier before it can possibly be dereferenced.

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 /> ocfs2: fix DIO failure due to insufficient transaction credits<br /> <br /> The code in ocfs2_dio_end_io_write() estimates number of necessary<br /> transaction credits using ocfs2_calc_extend_credits(). This however does<br /> not take into account that the IO could be arbitrarily large and can<br /> contain arbitrary number of extents.<br /> <br /> Extent tree manipulations do often extend the current transaction but not<br /> in all of the cases. For example if we have only single block extents in<br /> the tree, ocfs2_mark_extent_written() will end up calling<br /> ocfs2_replace_extent_rec() all the time and we will never extend the<br /> current transaction and eventually exhaust all the transaction credits if<br /> the IO contains many single block extents. Once that happens a<br /> WARN_ON(jbd2_handle_buffer_credits(handle)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/restrack: Fix potential invalid address access<br /> <br /> struct rdma_restrack_entry&amp;#39;s kern_name was set to KBUILD_MODNAME<br /> in ib_create_cq(), while if the module exited but forgot del this<br /> rdma_restrack_entry, it would cause a invalid address access in<br /> rdma_restrack_clean() when print the owner of this rdma_restrack_entry.<br /> <br /> These code is used to help find one forgotten PD release in one of the<br /> ULPs. But it is not needed anymore, so delete them.

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 /> 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.