Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: add missing check_func_arg_reg_off() to prevent out-of-bounds memory accesses<br /> <br /> Currently, it&amp;#39;s possible to pass in a modified CONST_PTR_TO_DYNPTR to<br /> a global function as an argument. The adverse effects of this is that<br /> BPF helpers can continue to make use of this modified<br /> CONST_PTR_TO_DYNPTR from within the context of the global function,<br /> which can unintentionally result in out-of-bounds memory accesses and<br /> therefore compromise overall system stability i.e.<br /> <br /> [ 244.157771] BUG: KASAN: slab-out-of-bounds in bpf_dynptr_data+0x137/0x140<br /> [ 244.161345] Read of size 8 at addr ffff88810914be68 by task test_progs/302<br /> [ 244.167151] CPU: 0 PID: 302 Comm: test_progs Tainted: G O E 6.10.0-rc3-00131-g66b586715063 #533<br /> [ 244.174318] Call Trace:<br /> [ 244.175787] <br /> [ 244.177356] dump_stack_lvl+0x66/0xa0<br /> [ 244.179531] print_report+0xce/0x670<br /> [ 244.182314] ? __virt_addr_valid+0x200/0x3e0<br /> [ 244.184908] kasan_report+0xd7/0x110<br /> [ 244.187408] ? bpf_dynptr_data+0x137/0x140<br /> [ 244.189714] ? bpf_dynptr_data+0x137/0x140<br /> [ 244.192020] bpf_dynptr_data+0x137/0x140<br /> [ 244.194264] bpf_prog_b02a02fdd2bdc5fa_global_call_bpf_dynptr_data+0x22/0x26<br /> [ 244.198044] bpf_prog_b0fe7b9d7dc3abde_callback_adjust_bpf_dynptr_reg_off+0x1f/0x23<br /> [ 244.202136] bpf_user_ringbuf_drain+0x2c7/0x570<br /> [ 244.204744] ? 0xffffffffc0009e58<br /> [ 244.206593] ? __pfx_bpf_user_ringbuf_drain+0x10/0x10<br /> [ 244.209795] bpf_prog_33ab33f6a804ba2d_user_ringbuf_callback_const_ptr_to_dynptr_reg_off+0x47/0x4b<br /> [ 244.215922] bpf_trampoline_6442502480+0x43/0xe3<br /> [ 244.218691] __x64_sys_prlimit64+0x9/0xf0<br /> [ 244.220912] do_syscall_64+0xc1/0x1d0<br /> [ 244.223043] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 244.226458] RIP: 0033:0x7ffa3eb8f059<br /> [ 244.228582] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8f 1d 0d 00 f7 d8 64 89 01 48<br /> [ 244.241307] RSP: 002b:00007ffa3e9c6eb8 EFLAGS: 00000206 ORIG_RAX: 000000000000012e<br /> [ 244.246474] RAX: ffffffffffffffda RBX: 00007ffa3e9c7cdc RCX: 00007ffa3eb8f059<br /> [ 244.250478] RDX: 00007ffa3eb162b4 RSI: 0000000000000000 RDI: 00007ffa3e9c7fb0<br /> [ 244.255396] RBP: 00007ffa3e9c6ed0 R08: 00007ffa3e9c76c0 R09: 0000000000000000<br /> [ 244.260195] R10: 0000000000000000 R11: 0000000000000206 R12: ffffffffffffff80<br /> [ 244.264201] R13: 000000000000001c R14: 00007ffc5d6b4260 R15: 00007ffa3e1c7000<br /> [ 244.268303] <br /> <br /> Add a check_func_arg_reg_off() to the path in which the BPF verifier<br /> verifies the arguments of global function arguments, specifically<br /> those which take an argument of type ARG_PTR_TO_DYNPTR |<br /> MEM_RDONLY. Also, process_dynptr_func() doesn&amp;#39;t appear to perform any<br /> explicit and strict type matching on the supplied register type, so<br /> let&amp;#39;s also enforce that a register either type PTR_TO_STACK or<br /> CONST_PTR_TO_DYNPTR is by the caller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: disallow setting special AP channel widths<br /> <br /> Setting the AP channel width is meant for use with the normal<br /> 20/40/... MHz channel width progression, and switching around<br /> in S1G or narrow channels isn&amp;#39;t supported. Disallow that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: avoid BUG_ON() while continue reshape after reassembling<br /> <br /> Currently, mdadm support --revert-reshape to abort the reshape while<br /> reassembling, as the test 07revert-grow. However, following BUG_ON()<br /> can be triggerred by the test:<br /> <br /> kernel BUG at drivers/md/raid5.c:6278!<br /> invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> irq event stamp: 158985<br /> CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94<br /> RIP: 0010:reshape_request+0x3f1/0xe60<br /> Call Trace:<br /> <br /> raid5_sync_request+0x43d/0x550<br /> md_do_sync+0xb7a/0x2110<br /> md_thread+0x294/0x2b0<br /> kthread+0x147/0x1c0<br /> ret_from_fork+0x59/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Root cause is that --revert-reshape update the raid_disks from 5 to 4,<br /> while reshape position is still set, and after reassembling the array,<br /> reshape position will be read from super block, then during reshape the<br /> checking of &amp;#39;writepos&amp;#39; that is caculated by old reshape position will<br /> fail.<br /> <br /> Fix this panic the easy way first, by converting the BUG_ON() to<br /> WARN_ON(), and stop the reshape if checkings fail.<br /> <br /> Noted that mdadm must fix --revert-shape as well, and probably md/raid<br /> should enhance metadata validation as well, however this means<br /> reassemble will fail and there must be user tools to fix the wrong<br /> metadata.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix UAFs when destroying the queues<br /> <br /> The second tagged commit started sometimes (very rarely, but possible)<br /> throwing WARNs from<br /> net/core/page_pool.c:page_pool_disable_direct_recycling().<br /> Turned out idpf frees interrupt vectors with embedded NAPIs *before*<br /> freeing the queues making page_pools&amp;#39; NAPI pointers lead to freed<br /> memory before these pools are destroyed by libeth.<br /> It&amp;#39;s not clear whether there are other accesses to the freed vectors<br /> when destroying the queues, but anyway, we usually free queue/interrupt<br /> vectors only when the queues are destroyed and the NAPIs are guaranteed<br /> to not be referenced anywhere.<br /> <br /> Invert the allocation and freeing logic making queue/interrupt vectors<br /> be allocated first and freed last. Vectors don&amp;#39;t require queues to be<br /> present, so this is safe. Additionally, this change allows to remove<br /> that useless queue-&gt;q_vector pointer cleanup, as vectors are still<br /> valid when freeing the queues (+ both are freed within one function,<br /> so it&amp;#39;s not clear why nullify the pointers at all).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en : Fix memory out-of-bounds in bnxt_fill_hw_rss_tbl()<br /> <br /> A recent commit has modified the code in __bnxt_reserve_rings() to<br /> set the default RSS indirection table to default only when the number<br /> of RX rings is changing. While this works for newer firmware that<br /> requires RX ring reservations, it causes the regression on older<br /> firmware not requiring RX ring resrvations (BNXT_NEW_RM() returns<br /> false).<br /> <br /> With older firmware, RX ring reservations are not required and so<br /> hw_resc-&gt;resv_rx_rings is not always set to the proper value. The<br /> comparison:<br /> <br /> if (old_rx_rings != bp-&gt;hw_resc.resv_rx_rings)<br /> <br /> in __bnxt_reserve_rings() may be false even when the RX rings are<br /> changing. This will cause __bnxt_reserve_rings() to skip setting<br /> the default RSS indirection table to default to match the current<br /> number of RX rings. This may later cause bnxt_fill_hw_rss_tbl() to<br /> use an out-of-range index.<br /> <br /> We already have bnxt_check_rss_tbl_no_rmgr() to handle exactly this<br /> scenario. We just need to move it up in bnxt_need_reserve_rings()<br /> to be called unconditionally when using older firmware. Without the<br /> fix, if the TX rings are changing, we&amp;#39;ll skip the<br /> bnxt_check_rss_tbl_no_rmgr() call and __bnxt_reserve_rings() may also<br /> skip the bnxt_set_dflt_rss_indir_tbl() call for the reason explained<br /> in the last paragraph. Without setting the default RSS indirection<br /> table to default, it causes the regression:<br /> <br /> BUG: KASAN: slab-out-of-bounds in __bnxt_hwrm_vnic_set_rss+0xb79/0xe40<br /> Read of size 2 at addr ffff8881c5809618 by task ethtool/31525<br /> Call Trace:<br /> __bnxt_hwrm_vnic_set_rss+0xb79/0xe40<br /> bnxt_hwrm_vnic_rss_cfg_p5+0xf7/0x460<br /> __bnxt_setup_vnic_p5+0x12e/0x270<br /> __bnxt_open_nic+0x2262/0x2f30<br /> bnxt_open_nic+0x5d/0xf0<br /> ethnl_set_channels+0x5d4/0xb30<br /> ethnl_default_set_doit+0x2f1/0x620

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: mcast: wait for previous gc cycles when removing port<br /> <br /> syzbot hit a use-after-free[1] which is caused because the bridge doesn&amp;#39;t<br /> make sure that all previous garbage has been collected when removing a<br /> port. What happens is:<br /> CPU 1 CPU 2<br /> start gc cycle remove port<br /> acquire gc lock first<br /> wait for lock<br /> call br_multicasg_gc() directly<br /> acquire lock now but free port<br /> the port can be freed<br /> while grp timers still<br /> running<br /> <br /> Make sure all previous gc cycles have finished by using flush_work before<br /> freeing the port.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861<br /> Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699<br /> <br /> CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0xc3/0x620 mm/kasan/report.c:488<br /> kasan_report+0xd9/0x110 mm/kasan/report.c:601<br /> br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861<br /> call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792<br /> expire_timers kernel/time/timer.c:1843 [inline]<br /> __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417<br /> __run_timer_base kernel/time/timer.c:2428 [inline]<br /> __run_timer_base kernel/time/timer.c:2421 [inline]<br /> run_timer_base+0x111/0x190 kernel/time/timer.c:2437

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: Fix null-ptr-deref in reuseport_add_sock().<br /> <br /> syzbot reported a null-ptr-deref while accessing sk2-&gt;sk_reuseport_cb in<br /> reuseport_add_sock(). [0]<br /> <br /> The repro first creates a listener with SO_REUSEPORT. Then, it creates<br /> another listener on the same port and concurrently closes the first<br /> listener.<br /> <br /> The second listen() calls reuseport_add_sock() with the first listener as<br /> sk2, where sk2-&gt;sk_reuseport_cb is not expected to be cleared concurrently,<br /> but the close() does clear it by reuseport_detach_sock().<br /> <br /> The problem is SCTP does not properly synchronise reuseport_alloc(),<br /> reuseport_add_sock(), and reuseport_detach_sock().<br /> <br /> The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must<br /> provide synchronisation for sockets that are classified into the same<br /> reuseport group.<br /> <br /> Otherwise, such sockets form multiple identical reuseport groups, and<br /> all groups except one would be silently dead.<br /> <br /> 1. Two sockets call listen() concurrently<br /> 2. No socket in the same group found in sctp_ep_hashtable[]<br /> 3. Two sockets call reuseport_alloc() and form two reuseport groups<br /> 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives<br /> incoming packets<br /> <br /> Also, the reported null-ptr-deref could occur.<br /> <br /> TCP/UDP guarantees that would not happen by holding the hash bucket lock.<br /> <br /> Let&amp;#39;s apply the locking strategy to __sctp_hash_endpoint() and<br /> __sctp_unhash_endpoint().<br /> <br /> [0]:<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024<br /> RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350<br /> Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14<br /> RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202<br /> RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012<br /> RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385<br /> R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0<br /> R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __sctp_hash_endpoint net/sctp/input.c:762 [inline]<br /> sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790<br /> sctp_listen_start net/sctp/socket.c:8570 [inline]<br /> sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625<br /> __sys_listen_socket net/socket.c:1883 [inline]<br /> __sys_listen+0x1b7/0x230 net/socket.c:1894<br /> __do_sys_listen net/socket.c:1902 [inline]<br /> __se_sys_listen net/socket.c:1900 [inline]<br /> __x64_sys_listen+0x5a/0x70 net/socket.c:1900<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f24e46039b9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032<br /> RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9<br /> RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004<br /> RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0<br /> R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c<br /> R13:<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: rt5033: Bring back i2c_set_clientdata<br /> <br /> Commit 3a93da231c12 ("power: supply: rt5033: Use devm_power_supply_register() helper")<br /> reworked the driver to use devm. While at it, the i2c_set_clientdata<br /> was dropped along with the remove callback. Unfortunately other parts<br /> of the driver also rely on i2c clientdata so this causes kernel oops.<br /> <br /> Bring the call back to fix the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: intel-vbtn: Protect ACPI notify handler against recursion<br /> <br /> Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on<br /> all CPUs") ACPI notify handlers like the intel-vbtn notify_handler() may<br /> run on multiple CPU cores racing with themselves.<br /> <br /> This race gets hit on Dell Venue 7140 tablets when undocking from<br /> the keyboard, causing the handler to try and register priv-&gt;switches_dev<br /> twice, as can be seen from the dev_info() message getting logged twice:<br /> <br /> [ 83.861800] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event<br /> [ 83.861858] input: Intel Virtual Switches as /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17<br /> [ 83.861865] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event<br /> <br /> After which things go seriously wrong:<br /> [ 83.861872] sysfs: cannot create duplicate filename &amp;#39;/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17&amp;#39;<br /> ...<br /> [ 83.861967] kobject: kobject_add_internal failed for input17 with -EEXIST, don&amp;#39;t try to register things with the same name in the same directory.<br /> [ 83.877338] BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> ...<br /> <br /> Protect intel-vbtn notify_handler() from racing with itself with a mutex<br /> to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: apple: fix device reference counting<br /> <br /> Drivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl.<br /> Split the allocation side out to make the error handling boundary easier<br /> to navigate. The apple driver had been doing this wrong, leaking the<br /> controller device memory on a tagset failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix NULL dereference at band check in starting tx ba session<br /> <br /> In MLD connection, link_data/link_conf are dynamically allocated. They<br /> don&amp;#39;t point to vif-&gt;bss_conf. So, there will be no chanreq assigned to<br /> vif-&gt;bss_conf and then the chan will be NULL. Tweak the code to check<br /> ht_supported/vht_supported/has_he/has_eht on sta deflink.<br /> <br /> Crash log (with rtw89 version under MLO development):<br /> [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 9890.526102] #PF: supervisor read access in kernel mode<br /> [ 9890.526105] #PF: error_code(0x0000) - not-present page<br /> [ 9890.526109] PGD 0 P4D 0<br /> [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1<br /> [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018<br /> [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core]<br /> [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211<br /> [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3<br /> All code<br /> ========<br /> 0: f7 e8 imul %eax<br /> 2: d5 (bad)<br /> 3: 93 xchg %eax,%ebx<br /> 4: 3e ea ds (bad)<br /> 6: 48 83 c4 28 add $0x28,%rsp<br /> a: 89 d8 mov %ebx,%eax<br /> c: 5b pop %rbx<br /> d: 41 5c pop %r12<br /> f: 41 5d pop %r13<br /> 11: 41 5e pop %r14<br /> 13: 41 5f pop %r15<br /> 15: 5d pop %rbp<br /> 16: c3 retq<br /> 17: cc int3<br /> 18: cc int3<br /> 19: cc int3<br /> 1a: cc int3<br /> 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax<br /> 22: ff<br /> 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax<br /> 2a:* 83 38 03 cmpl $0x3,(%rax)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix overflow in get_free_elt()<br /> <br /> "tracing_map-&gt;next_elt" in get_free_elt() is at risk of overflowing.<br /> <br /> Once it overflows, new elements can still be inserted into the tracing_map<br /> even though the maximum number of elements (`max_elts`) has been reached.<br /> Continuing to insert elements after the overflow could result in the<br /> tracing_map containing "tracing_map-&gt;max_size" elements, leaving no empty<br /> entries.<br /> If any attempt is made to insert an element into a full tracing_map using<br /> `__tracing_map_insert()`, it will cause an infinite loop with preemption<br /> disabled, leading to a CPU hang problem.<br /> <br /> Fix this by preventing any further increments to "tracing_map-&gt;next_elt"<br /> once it reaches "tracing_map-&gt;max_elt".