Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-flakey: Fix memory corruption in optional corrupt_bio_byte feature<br /> <br /> Fix memory corruption due to incorrect parameter being passed to bio_init

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in ksmbd_free_work_struct<br /> <br /> -&gt;interim_entry of ksmbd_work could be deleted after oplock is freed.<br /> We don&amp;#39;t need to manage it with linked list. The interim request could be<br /> immediately sent whenever a oplock break wait is needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree()<br /> <br /> Since commit b36e4523d4d5 ("netfilter: nf_conncount: fix garbage<br /> collection confirm race"), `cpu` and `jiffies32` were introduced to<br /> the struct nf_conncount_tuple.<br /> <br /> The commit made nf_conncount_add() initialize `conn-&gt;cpu` and<br /> `conn-&gt;jiffies32` when allocating the struct.<br /> In contrast, count_tree() was not changed to initialize them.<br /> <br /> By commit 34848d5c896e ("netfilter: nf_conncount: Split insert and<br /> traversal"), count_tree() was split and the relevant allocation<br /> code now resides in insert_tree().<br /> Initialize `conn-&gt;cpu` and `conn-&gt;jiffies32` in insert_tree().<br /> <br /> BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline]<br /> BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143<br /> find_or_evict net/netfilter/nf_conncount.c:117 [inline]<br /> __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143<br /> count_tree net/netfilter/nf_conncount.c:438 [inline]<br /> nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521<br /> connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72<br /> __nft_match_eval net/netfilter/nft_compat.c:403 [inline]<br /> nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433<br /> expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]<br /> nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288<br /> nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626<br /> nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663<br /> NF_HOOK_LIST include/linux/netfilter.h:350 [inline]<br /> ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633<br /> ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669<br /> __netif_receive_skb_list_ptype net/core/dev.c:5936 [inline]<br /> __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983<br /> __netif_receive_skb_list net/core/dev.c:6035 [inline]<br /> netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126<br /> netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178<br /> xdp_recv_frames net/bpf/test_run.c:280 [inline]<br /> xdp_test_run_batch net/bpf/test_run.c:361 [inline]<br /> bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390<br /> bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316<br /> bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407<br /> __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813<br /> __do_sys_bpf kernel/bpf/syscall.c:5902 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5900 [inline]<br /> __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900<br /> ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]<br /> __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387<br /> do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450<br /> entry_SYSENTER_compat_after_hwframe+0x84/0x8e<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4121 [inline]<br /> slab_alloc_node mm/slub.c:4164 [inline]<br /> kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171<br /> insert_tree net/netfilter/nf_conncount.c:372 [inline]<br /> count_tree net/netfilter/nf_conncount.c:450 [inline]<br /> nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521<br /> connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72<br /> __nft_match_eval net/netfilter/nft_compat.c:403 [inline]<br /> nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433<br /> expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]<br /> nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288<br /> nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626<br /> nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663<br /> NF_HOOK_LIST include/linux/netfilter.h:350 [inline]<br /> ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633<br /> ip_list_rcv+0x9ef/0xa40 net/ip<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: bnxt: do not update checksum in bnxt_xdp_build_skb()<br /> <br /> The bnxt_rx_pkt() updates ip_summed value at the end if checksum offload<br /> is enabled.<br /> When the XDP-MB program is attached and it returns XDP_PASS, the<br /> bnxt_xdp_build_skb() is called to update skb_shared_info.<br /> The main purpose of bnxt_xdp_build_skb() is to update skb_shared_info,<br /> but it updates ip_summed value too if checksum offload is enabled.<br /> This is actually duplicate work.<br /> <br /> When the bnxt_rx_pkt() updates ip_summed value, it checks if ip_summed<br /> is CHECKSUM_NONE or not.<br /> It means that ip_summed should be CHECKSUM_NONE at this moment.<br /> But ip_summed may already be updated to CHECKSUM_UNNECESSARY in the<br /> XDP-MB-PASS path.<br /> So the by skb_checksum_none_assert() WARNS about it.<br /> <br /> This is duplicate work and updating ip_summed in the<br /> bnxt_xdp_build_skb() is not needed.<br /> <br /> Splat looks like:<br /> WARNING: CPU: 3 PID: 5782 at ./include/linux/skbuff.h:5155 bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]<br /> Modules linked in: bnxt_re bnxt_en rdma_ucm rdma_cm iw_cm ib_cm ib_uverbs veth xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_]<br /> CPU: 3 UID: 0 PID: 5782 Comm: socat Tainted: G W 6.14.0-rc4+ #27<br /> Tainted: [W]=WARN<br /> Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021<br /> RIP: 0010:bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]<br /> Code: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff 0b f<br /> RSP: 0018:ffff88881ba09928 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000<br /> RDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8<br /> RBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070<br /> R10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080<br /> R13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000<br /> FS: 00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn+0xcd/0x2f0<br /> ? bnxt_rx_pkt+0x479b/0x7610<br /> ? report_bug+0x326/0x3c0<br /> ? handle_bug+0x53/0xa0<br /> ? exc_invalid_op+0x14/0x50<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? bnxt_rx_pkt+0x479b/0x7610<br /> ? bnxt_rx_pkt+0x3e41/0x7610<br /> ? __pfx_bnxt_rx_pkt+0x10/0x10<br /> ? napi_complete_done+0x2cf/0x7d0<br /> __bnxt_poll_work+0x4e8/0x1220<br /> ? __pfx___bnxt_poll_work+0x10/0x10<br /> ? __pfx_mark_lock.part.0+0x10/0x10<br /> bnxt_poll_p5+0x36a/0xfa0<br /> ? __pfx_bnxt_poll_p5+0x10/0x10<br /> __napi_poll.constprop.0+0xa0/0x440<br /> net_rx_action+0x899/0xd00<br /> ...<br /> <br /> Following ping.py patch adds xdp-mb-pass case. so ping.py is going<br /> to be able to reproduce this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix integer overflow while processing closetimeo mount option<br /> <br /> User-provided mount parameter closetimeo of type u32 is intended to have<br /> an upper limit, but before it is validated, the value is converted from<br /> seconds to jiffies which can lead to an integer overflow.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix integer overflow while processing acdirmax mount option<br /> <br /> User-provided mount parameter acdirmax of type u32 is intended to have<br /> an upper limit, but before it is validated, the value is converted from<br /> seconds to jiffies which can lead to an integer overflow.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix integer overflow while processing acregmax mount option<br /> <br /> User-provided mount parameter acregmax of type u32 is intended to have<br /> an upper limit, but before it is validated, the value is converted from<br /> seconds to jiffies which can lead to an integer overflow.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: corsair-void: Update power supply values with a unified work handler<br /> <br /> corsair_void_process_receiver can be called from an interrupt context,<br /> locking battery_mutex in it was causing a kernel panic.<br /> Fix it by moving the critical section into its own work, sharing this<br /> work with battery_add_work and battery_remove_work to remove the need<br /> for any locking

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netmem: prevent TX of unreadable skbs<br /> <br /> Currently on stable trees we have support for netmem/devmem RX but not<br /> TX. It is not safe to forward/redirect an RX unreadable netmem packet<br /> into the device&amp;#39;s TX path, as the device may call dma-mapping APIs on<br /> dma addrs that should not be passed to it.<br /> <br /> Fix this by preventing the xmit of unreadable skbs.<br /> <br /> Tested by configuring tc redirect:<br /> <br /> sudo tc qdisc add dev eth1 ingress<br /> sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ip_proto \<br /> tcp src_ip 192.168.1.12 action mirred egress redirect dev eth1<br /> <br /> Before, I see unreadable skbs in the driver&amp;#39;s TX path passed to dma<br /> mapping APIs.<br /> <br /> After, I don&amp;#39;t see unreadable skbs in the driver&amp;#39;s TX path passed to dma<br /> mapping APIs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: prevent connection release during oplock break notification<br /> <br /> ksmbd_work could be freed when after connection release.<br /> Increment r_count of ksmbd_conn to indicate that requests<br /> are not finished yet and to not release the connection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Set hugetlb mmap base address aligned with pmd size<br /> <br /> With ltp test case "testcases/bin/hugefork02", there is a dmesg error<br /> report message such as:<br /> <br /> kernel BUG at mm/hugetlb.c:5550!<br /> Oops - BUG[#1]:<br /> CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022<br /> pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940<br /> a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000<br /> a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000<br /> t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000<br /> t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001<br /> t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280<br /> s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10<br /> s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08<br /> ra: 9000000000485538 unmap_vmas+0x130/0x218<br /> ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0<br /> PRMD: 00000004 (PPLV0 +PIE -PWE)<br /> EUEN: 00000007 (+FPE +SXE +ASXE -BTE)<br /> ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)<br /> PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)<br /> Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64)<br /> Call Trace:<br /> [] __unmap_hugepage_range+0x6f4/0x7d0<br /> [] unmap_vmas+0x12c/0x218<br /> [] exit_mmap+0xe0/0x308<br /> [] mmput+0x74/0x180<br /> [] do_exit+0x294/0x898<br /> [] do_group_exit+0x30/0x98<br /> [] get_signal+0x83c/0x868<br /> [] arch_do_signal_or_restart+0x54/0xfa0<br /> [] irqentry_exit_to_user_mode+0xb8/0x138<br /> [] tlb_do_page_fault_1+0x114/0x1b4<br /> <br /> The problem is that base address allocated from hugetlbfs is not aligned<br /> with pmd size. Here add a checking for hugetlbfs and align base address<br /> with pmd size. After this patch the test case "testcases/bin/hugefork02"<br /> passes to run.<br /> <br /> This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach<br /> generic_get_unmapped_area{_topdown} to handle hugetlb mappings").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: cleanup mana struct after debugfs_remove()<br /> <br /> When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(),<br /> mana_gd_suspend() and mana_gd_resume() are called. If during this<br /> mana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfs<br /> pointer does not get reinitialized and ends up pointing to older,<br /> cleaned-up dentry.<br /> Further in the hibernation path, as part of power_down(), mana_gd_shutdown()<br /> is triggered. This call, unaware of the failures in resume, tries to cleanup<br /> the already cleaned up mana_port_debugfs value and hits the following bug:<br /> <br /> [ 191.359296] mana 7870:00:00.0: Shutdown was called<br /> [ 191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098<br /> [ 191.360584] #PF: supervisor write access in kernel mode<br /> [ 191.361125] #PF: error_code(0x0002) - not-present page<br /> [ 191.361727] PGD 1080ea067 P4D 0<br /> [ 191.362172] Oops: Oops: 0002 [#1] SMP NOPTI<br /> [ 191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2<br /> [ 191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024<br /> [ 191.364124] RIP: 0010:down_write+0x19/0x50<br /> [ 191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d<br /> [ 191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246<br /> [ 191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000<br /> [ 191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098<br /> [ 191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001<br /> [ 191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000<br /> [ 191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020<br /> [ 191.369549] FS: 00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000<br /> [ 191.370213] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0<br /> [ 191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [ 191.372906] Call Trace:<br /> [ 191.373262] <br /> [ 191.373621] ? show_regs+0x64/0x70<br /> [ 191.374040] ? __die+0x24/0x70<br /> [ 191.374468] ? page_fault_oops+0x290/0x5b0<br /> [ 191.374875] ? do_user_addr_fault+0x448/0x800<br /> [ 191.375357] ? exc_page_fault+0x7a/0x160<br /> [ 191.375971] ? asm_exc_page_fault+0x27/0x30<br /> [ 191.376416] ? down_write+0x19/0x50<br /> [ 191.376832] ? down_write+0x12/0x50<br /> [ 191.377232] simple_recursive_removal+0x4a/0x2a0<br /> [ 191.377679] ? __pfx_remove_one+0x10/0x10<br /> [ 191.378088] debugfs_remove+0x44/0x70<br /> [ 191.378530] mana_detach+0x17c/0x4f0<br /> [ 191.378950] ? __flush_work+0x1e2/0x3b0<br /> [ 191.379362] ? __cond_resched+0x1a/0x50<br /> [ 191.379787] mana_remove+0xf2/0x1a0<br /> [ 191.380193] mana_gd_shutdown+0x3b/0x70<br /> [ 191.380642] pci_device_shutdown+0x3a/0x80<br /> [ 191.381063] device_shutdown+0x13e/0x230<br /> [ 191.381480] kernel_power_off+0x35/0x80<br /> [ 191.381890] hibernate+0x3c6/0x470<br /> [ 191.382312] state_store+0xcb/0xd0<br /> [ 191.382734] kobj_attr_store+0x12/0x30<br /> [ 191.383211] sysfs_kf_write+0x3e/0x50<br /> [ 191.383640] kernfs_fop_write_iter+0x140/0x1d0<br /> [ 191.384106] vfs_write+0x271/0x440<br /> [ 191.384521] ksys_write+0x72/0xf0<br /> [ 191.384924] __x64_sys_write+0x19/0x20<br /> [ 191.385313] x64_sys_call+0x2b0/0x20b0<br /> [ 191.385736] do_syscall_64+0x79/0x150<br /> [ 191.386146] ? __mod_memcg_lruvec_state+0xe7/0x240<br /> [ 191.386676] ? __lruvec_stat_mod_folio+0x79/0xb0<br /> [ 191.387124] ? __pfx_lru_add+0x10/0x10<br /> [ 191.387515] ? queued_spin_unlock+0x9/0x10<br /> [ 191.387937] ? do_anonymous_page+0x33c/0xa00<br /> [ 191.388374] ? __handle_mm_fault+0xcf3/0x1210<br /> [ 191.388805] ? __count_memcg_events+0xbe/0x180<br /> [ 191.389235] ? handle_mm_fault+0xae/0x300<br /> [ 19<br /> ---truncated---