Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Use raw_spinlock_t in ringbuf<br /> <br /> The function __bpf_ringbuf_reserve is invoked from a tracepoint, which<br /> disables preemption. Using spinlock_t in this context can lead to a<br /> "sleep in atomic" warning in the RT variant. This issue is illustrated<br /> in the example below:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 1, expected: 1<br /> INFO: lockdep is turned off.<br /> Preemption disabled at:<br /> [] migrate_enable+0xc0/0x39c<br /> CPU: 7 PID: 556208 Comm: test_progs Tainted: G<br /> Hardware name: Qualcomm SA8775P Ride (DT)<br /> Call trace:<br /> dump_backtrace+0xac/0x130<br /> show_stack+0x1c/0x30<br /> dump_stack_lvl+0xac/0xe8<br /> dump_stack+0x18/0x30<br /> __might_resched+0x3bc/0x4fc<br /> rt_spin_lock+0x8c/0x1a4<br /> __bpf_ringbuf_reserve+0xc4/0x254<br /> bpf_ringbuf_reserve_dynptr+0x5c/0xdc<br /> bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238<br /> trace_call_bpf+0x238/0x774<br /> perf_call_bpf_enter.isra.0+0x104/0x194<br /> perf_syscall_enter+0x2f8/0x510<br /> trace_sys_enter+0x39c/0x564<br /> syscall_trace_enter+0x220/0x3c0<br /> do_el0_svc+0x138/0x1dc<br /> el0_svc+0x54/0x130<br /> el0t_64_sync_handler+0x134/0x150<br /> el0t_64_sync+0x17c/0x180<br /> <br /> Switch the spinlock to raw_spinlock_t to avoid this error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Hold rescan lock while adding devices during host probe<br /> <br /> Since adding the PCI power control code, we may end up with a race between<br /> the pwrctl platform device rescanning the bus and host controller probe<br /> functions. The latter need to take the rescan lock when adding devices or<br /> we may end up in an undefined state having two incompletely added devices<br /> and hit the following crash when trying to remove the device over sysfs:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> Call trace:<br /> __pi_strlen+0x14/0x150<br /> kernfs_find_ns+0x80/0x13c<br /> kernfs_remove_by_name_ns+0x54/0xf0<br /> sysfs_remove_bin_file+0x24/0x34<br /> pci_remove_resource_files+0x3c/0x84<br /> pci_remove_sysfs_dev_files+0x28/0x38<br /> pci_stop_bus_device+0x8c/0xd8<br /> pci_stop_bus_device+0x40/0xd8<br /> pci_stop_and_remove_bus_device_locked+0x28/0x48<br /> remove_store+0x70/0xb0<br /> dev_attr_store+0x20/0x38<br /> sysfs_kf_write+0x58/0x78<br /> kernfs_fop_write_iter+0xe8/0x184<br /> vfs_write+0x2dc/0x308<br /> ksys_write+0x7c/0xec

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add the missing BPF_LINK_TYPE invocation for sockmap<br /> <br /> There is an out-of-bounds read in bpf_link_show_fdinfo() for the sockmap<br /> link fd. Fix it by adding the missing BPF_LINK_TYPE invocation for<br /> sockmap link<br /> <br /> Also add comments for bpf_link_type to prevent missing updates in the<br /> future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: pse-pd: Fix out of bound for loop<br /> <br /> Adjust the loop limit to prevent out-of-bounds access when iterating over<br /> PI structures. The loop should not reach the index pcdev-&gt;nr_lines since<br /> we allocate exactly pcdev-&gt;nr_lines number of PI structures. This fix<br /> ensures proper bounds are maintained during iterations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: bpf: must hold reference on net namespace<br /> <br /> BUG: KASAN: slab-use-after-free in __nf_unregister_net_hook+0x640/0x6b0<br /> Read of size 8 at addr ffff8880106fe400 by task repro/72=<br /> bpf_nf_link_release+0xda/0x1e0<br /> bpf_link_free+0x139/0x2d0<br /> bpf_link_release+0x68/0x80<br /> __fput+0x414/0xb60<br /> <br /> Eric says:<br /> It seems that bpf was able to defer the __nf_unregister_net_hook()<br /> after exit()/close() time.<br /> Perhaps a netns reference is missing, because the netns has been<br /> dismantled/freed already.<br /> bpf_nf_link_attach() does :<br /> link-&gt;net = net;<br /> But I do not see a reference being taken on net.<br /> <br /> Add such a reference and release it after hook unreg.<br /> Note that I was unable to get syzbot reproducer to work, so I<br /> do not know if this resolves this splat.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/probes: Fix MAX_TRACE_ARGS limit handling<br /> <br /> When creating a trace_probe we would set nr_args prior to truncating the<br /> arguments to MAX_TRACE_ARGS. However, we would only initialize arguments<br /> up to the limit.<br /> <br /> This caused invalid memory access when attempting to set up probes with<br /> more than 128 fetchargs.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 UID: 0 PID: 1769 Comm: cat Not tainted 6.11.0-rc7+ #8<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014<br /> RIP: 0010:__set_print_fmt+0x134/0x330<br /> <br /> Resolve the issue by applying the MAX_TRACE_ARGS limit earlier. Return<br /> an error when there are too many arguments instead of silently<br /> truncating.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net<br /> <br /> In the normal case, when we excute `echo 0 &gt; /proc/fs/nfsd/threads`, the<br /> function `nfs4_state_destroy_net` in `nfs4_state_shutdown_net` will<br /> release all resources related to the hashed `nfs4_client`. If the<br /> `nfsd_client_shrinker` is running concurrently, the `expire_client`<br /> function will first unhash this client and then destroy it. This can<br /> lead to the following warning. Additionally, numerous use-after-free<br /> errors may occur as well.<br /> <br /> nfsd_client_shrinker echo 0 &gt; /proc/fs/nfsd/threads<br /> <br /> expire_client nfsd_shutdown_net<br /> unhash_client ...<br /> nfs4_state_shutdown_net<br /> /* won&amp;#39;t wait shrinker exit */<br /> /* cancel_work(&amp;nn-&gt;nfsd_shrinker_work)<br /> * nfsd_file for this /* won&amp;#39;t destroy unhashed client1 */<br /> * client1 still alive nfs4_state_destroy_net<br /> */<br /> <br /> nfsd_file_cache_shutdown<br /> /* trigger warning */<br /> kmem_cache_destroy(nfsd_file_slab)<br /> kmem_cache_destroy(nfsd_file_mark_slab)<br /> /* release nfsd_file and mark */<br /> __destroy_client<br /> <br /> ====================================================================<br /> BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on<br /> __kmem_cache_shutdown()<br /> --------------------------------------------------------------------<br /> CPU: 4 UID: 0 PID: 764 Comm: sh Not tainted 6.12.0-rc3+ #1<br /> <br /> dump_stack_lvl+0x53/0x70<br /> slab_err+0xb0/0xf0<br /> __kmem_cache_shutdown+0x15c/0x310<br /> kmem_cache_destroy+0x66/0x160<br /> nfsd_file_cache_shutdown+0xac/0x210 [nfsd]<br /> nfsd_destroy_serv+0x251/0x2a0 [nfsd]<br /> nfsd_svc+0x125/0x1e0 [nfsd]<br /> write_threads+0x16a/0x2a0 [nfsd]<br /> nfsctl_transaction_write+0x74/0xa0 [nfsd]<br /> vfs_write+0x1a5/0x6d0<br /> ksys_write+0xc1/0x160<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> ====================================================================<br /> BUG nfsd_file_mark (Tainted: G B W ): Objects remaining<br /> nfsd_file_mark on __kmem_cache_shutdown()<br /> --------------------------------------------------------------------<br /> <br /> dump_stack_lvl+0x53/0x70<br /> slab_err+0xb0/0xf0<br /> __kmem_cache_shutdown+0x15c/0x310<br /> kmem_cache_destroy+0x66/0x160<br /> nfsd_file_cache_shutdown+0xc8/0x210 [nfsd]<br /> nfsd_destroy_serv+0x251/0x2a0 [nfsd]<br /> nfsd_svc+0x125/0x1e0 [nfsd]<br /> write_threads+0x16a/0x2a0 [nfsd]<br /> nfsctl_transaction_write+0x74/0xa0 [nfsd]<br /> vfs_write+0x1a5/0x6d0<br /> ksys_write+0xc1/0x160<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> To resolve this issue, cancel `nfsd_shrinker_work` using synchronous<br /> mode in nfs4_state_shutdown_net.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: Fix UAF on iso_sock_timeout<br /> <br /> conn-&gt;sk maybe have been unlinked/freed while waiting for iso_conn_lock<br /> so this checks if the conn-&gt;sk is still valid by checking if it part of<br /> iso_sk_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SCO: Fix UAF on sco_sock_timeout<br /> <br /> conn-&gt;sk maybe have been unlinked/freed while waiting for sco_conn_lock<br /> so this checks if the conn-&gt;sk is still valid by checking if it part of<br /> sco_sk_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: use RCU read-side critical section in taprio_dump()<br /> <br /> Fix possible use-after-free in &amp;#39;taprio_dump()&amp;#39; by adding RCU<br /> read-side critical section there. Never seen on x86 but<br /> found on a KASAN-enabled arm64 system when investigating<br /> https://syzkaller.appspot.com/bug?extid=b65e0af58423fc8a73aa:<br /> <br /> [T15862] BUG: KASAN: slab-use-after-free in taprio_dump+0xa0c/0xbb0<br /> [T15862] Read of size 4 at addr ffff0000d4bb88f8 by task repro/15862<br /> [T15862]<br /> [T15862] CPU: 0 UID: 0 PID: 15862 Comm: repro Not tainted 6.11.0-rc1-00293-gdefaf1a2113a-dirty #2<br /> [T15862] Hardware name: QEMU QEMU Virtual Machine, BIOS edk2-20240524-5.fc40 05/24/2024<br /> [T15862] Call trace:<br /> [T15862] dump_backtrace+0x20c/0x220<br /> [T15862] show_stack+0x2c/0x40<br /> [T15862] dump_stack_lvl+0xf8/0x174<br /> [T15862] print_report+0x170/0x4d8<br /> [T15862] kasan_report+0xb8/0x1d4<br /> [T15862] __asan_report_load4_noabort+0x20/0x2c<br /> [T15862] taprio_dump+0xa0c/0xbb0<br /> [T15862] tc_fill_qdisc+0x540/0x1020<br /> [T15862] qdisc_notify.isra.0+0x330/0x3a0<br /> [T15862] tc_modify_qdisc+0x7b8/0x1838<br /> [T15862] rtnetlink_rcv_msg+0x3c8/0xc20<br /> [T15862] netlink_rcv_skb+0x1f8/0x3d4<br /> [T15862] rtnetlink_rcv+0x28/0x40<br /> [T15862] netlink_unicast+0x51c/0x790<br /> [T15862] netlink_sendmsg+0x79c/0xc20<br /> [T15862] __sock_sendmsg+0xe0/0x1a0<br /> [T15862] ____sys_sendmsg+0x6c0/0x840<br /> [T15862] ___sys_sendmsg+0x1ac/0x1f0<br /> [T15862] __sys_sendmsg+0x110/0x1d0<br /> [T15862] __arm64_sys_sendmsg+0x74/0xb0<br /> [T15862] invoke_syscall+0x88/0x2e0<br /> [T15862] el0_svc_common.constprop.0+0xe4/0x2a0<br /> [T15862] do_el0_svc+0x44/0x60<br /> [T15862] el0_svc+0x50/0x184<br /> [T15862] el0t_64_sync_handler+0x120/0x12c<br /> [T15862] el0t_64_sync+0x190/0x194<br /> [T15862]<br /> [T15862] Allocated by task 15857:<br /> [T15862] kasan_save_stack+0x3c/0x70<br /> [T15862] kasan_save_track+0x20/0x3c<br /> [T15862] kasan_save_alloc_info+0x40/0x60<br /> [T15862] __kasan_kmalloc+0xd4/0xe0<br /> [T15862] __kmalloc_cache_noprof+0x194/0x334<br /> [T15862] taprio_change+0x45c/0x2fe0<br /> [T15862] tc_modify_qdisc+0x6a8/0x1838<br /> [T15862] rtnetlink_rcv_msg+0x3c8/0xc20<br /> [T15862] netlink_rcv_skb+0x1f8/0x3d4<br /> [T15862] rtnetlink_rcv+0x28/0x40<br /> [T15862] netlink_unicast+0x51c/0x790<br /> [T15862] netlink_sendmsg+0x79c/0xc20<br /> [T15862] __sock_sendmsg+0xe0/0x1a0<br /> [T15862] ____sys_sendmsg+0x6c0/0x840<br /> [T15862] ___sys_sendmsg+0x1ac/0x1f0<br /> [T15862] __sys_sendmsg+0x110/0x1d0<br /> [T15862] __arm64_sys_sendmsg+0x74/0xb0<br /> [T15862] invoke_syscall+0x88/0x2e0<br /> [T15862] el0_svc_common.constprop.0+0xe4/0x2a0<br /> [T15862] do_el0_svc+0x44/0x60<br /> [T15862] el0_svc+0x50/0x184<br /> [T15862] el0t_64_sync_handler+0x120/0x12c<br /> [T15862] el0t_64_sync+0x190/0x194<br /> [T15862]<br /> [T15862] Freed by task 6192:<br /> [T15862] kasan_save_stack+0x3c/0x70<br /> [T15862] kasan_save_track+0x20/0x3c<br /> [T15862] kasan_save_free_info+0x4c/0x80<br /> [T15862] poison_slab_object+0x110/0x160<br /> [T15862] __kasan_slab_free+0x3c/0x74<br /> [T15862] kfree+0x134/0x3c0<br /> [T15862] taprio_free_sched_cb+0x18c/0x220<br /> [T15862] rcu_core+0x920/0x1b7c<br /> [T15862] rcu_core_si+0x10/0x1c<br /> [T15862] handle_softirqs+0x2e8/0xd64<br /> [T15862] __do_softirq+0x14/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: fix use-after-free in taprio_change()<br /> <br /> In &amp;#39;taprio_change()&amp;#39;, &amp;#39;admin&amp;#39; pointer may become dangling due to sched<br /> switch / removal caused by &amp;#39;advance_sched()&amp;#39;, and critical section<br /> protected by &amp;#39;q-&gt;current_entry_lock&amp;#39; is too small to prevent from such<br /> a scenario (which causes use-after-free detected by KASAN). Fix this<br /> by prefer &amp;#39;rcu_replace_pointer()&amp;#39; over &amp;#39;rcu_assign_pointer()&amp;#39; to update<br /> &amp;#39;admin&amp;#39; immediately before an attempt to schedule freeing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: fix global oob in wwan_rtnl_policy<br /> <br /> The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to<br /> a global out-of-bounds read when parsing the netlink attributes. Exactly<br /> same bug cause as the oob fixed in commit b33fb5b801c6 ("net: qualcomm:<br /> rmnet: fix global oob in rmnet_policy").<br /> <br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline]<br /> BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603<br /> Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862<br /> <br /> CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:284 [inline]<br /> print_report+0x14f/0x750 mm/kasan/report.c:395<br /> kasan_report+0x139/0x170 mm/kasan/report.c:495<br /> validate_nla lib/nlattr.c:388 [inline]<br /> __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603<br /> __nla_parse+0x3c/0x50 lib/nlattr.c:700<br /> nla_parse_nested_deprecated include/net/netlink.h:1269 [inline]<br /> __rtnl_newlink net/core/rtnetlink.c:3514 [inline]<br /> rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623<br /> rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122<br /> netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline]<br /> netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352<br /> netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874<br /> sock_sendmsg_nosec net/socket.c:716 [inline]<br /> __sock_sendmsg net/socket.c:728 [inline]<br /> ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499<br /> ___sys_sendmsg+0x21c/0x290 net/socket.c:2553<br /> __sys_sendmsg net/socket.c:2582 [inline]<br /> __do_sys_sendmsg net/socket.c:2591 [inline]<br /> __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f67b19a24ad<br /> RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad<br /> RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004<br /> RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40<br /> <br /> <br /> The buggy address belongs to the variable:<br /> wwan_rtnl_policy+0x20/0x40<br /> <br /> The buggy address belongs to the physical page:<br /> page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c<br /> flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff)<br /> raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner info is not present (never set?)<br /> <br /> Memory state around the buggy address:<br /> ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9<br /> ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9<br /> &gt;ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9<br /> ^<br /> ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ==================================================================<br /> <br /> According to the comment of `nla_parse_nested_deprecated`, use correct size<br /> `IFLA_WWAN_MAX` here to fix this issue.