Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: avoid UAF for reorder_work<br /> <br /> Although the previous patch can avoid ps and ps UAF for _do_serial, it<br /> can not avoid potential UAF issue for reorder_work. This issue can<br /> happen just as below:<br /> <br /> crypto_request crypto_request crypto_del_alg<br /> padata_do_serial<br /> ...<br /> padata_reorder<br /> // processes all remaining<br /> // requests then breaks<br /> while (1) {<br /> if (!padata)<br /> break;<br /> ...<br /> }<br /> <br /> padata_do_serial<br /> // new request added<br /> list_add<br /> // sees the new request<br /> queue_work(reorder_work)<br /> padata_reorder<br /> queue_work_on(squeue-&gt;work)<br /> ...<br /> <br /> <br /> padata_serial_worker<br /> // completes new request,<br /> // no more outstanding<br /> // requests<br /> <br /> crypto_del_alg<br /> // free pd<br /> <br /> <br /> invoke_padata_reorder<br /> // UAF of pd<br /> <br /> To avoid UAF for &amp;#39;reorder_work&amp;#39;, get &amp;#39;pd&amp;#39; ref before put &amp;#39;reorder_work&amp;#39;<br /> into the &amp;#39;serial_wq&amp;#39; and put &amp;#39;pd&amp;#39; ref until the &amp;#39;serial_wq&amp;#39; finish.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: fix UAF in padata_reorder<br /> <br /> A bug was found when run ltp test:<br /> <br /> BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0<br /> Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206<br /> <br /> CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+<br /> Workqueue: pdecrypt_parallel padata_parallel_worker<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x32/0x50<br /> print_address_description.constprop.0+0x6b/0x3d0<br /> print_report+0xdd/0x2c0<br /> kasan_report+0xa5/0xd0<br /> padata_find_next+0x29/0x1a0<br /> padata_reorder+0x131/0x220<br /> padata_parallel_worker+0x3d/0xc0<br /> process_one_work+0x2ec/0x5a0<br /> <br /> If &amp;#39;mdelay(10)&amp;#39; is added before calling &amp;#39;padata_find_next&amp;#39; in the<br /> &amp;#39;padata_reorder&amp;#39; function, this issue could be reproduced easily with<br /> ltp test (pcrypt_aead01).<br /> <br /> This can be explained as bellow:<br /> <br /> pcrypt_aead_encrypt<br /> ...<br /> padata_do_parallel<br /> refcount_inc(&amp;pd-&gt;refcnt); // add refcnt<br /> ...<br /> padata_do_serial<br /> padata_reorder // pd<br /> while (1) {<br /> padata_find_next(pd, true); // using pd<br /> queue_work_on<br /> ...<br /> padata_serial_worker crypto_del_alg<br /> padata_put_pd_cnt // sub refcnt<br /> padata_free_shell<br /> padata_put_pd(ps-&gt;pd);<br /> // pd is freed<br /> // loop again, but pd is freed<br /> // call padata_find_next, UAF<br /> }<br /> <br /> In the padata_reorder function, when it loops in &amp;#39;while&amp;#39;, if the alg is<br /> deleted, the refcnt may be decreased to 0 before entering<br /> &amp;#39;padata_find_next&amp;#39;, which leads to UAF.<br /> <br /> As mentioned in [1], do_serial is supposed to be called with BHs disabled<br /> and always happen under RCU protection, to address this issue, add<br /> synchronize_rcu() in &amp;#39;padata_free_shell&amp;#39; wait for all _do_serial calls<br /> to finish.<br /> <br /> [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/<br /> [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Send signals asynchronously if !preemptible<br /> <br /> BPF programs can execute in all kinds of contexts and when a program<br /> running in a non-preemptible context uses the bpf_send_signal() kfunc,<br /> it will cause issues because this kfunc can sleep.<br /> Change `irqs_disabled()` to `!preemptible()`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: don&amp;#39;t allow reconnect after disconnect<br /> <br /> Following process can cause nbd_config UAF:<br /> <br /> 1) grab nbd_config temporarily;<br /> <br /> 2) nbd_genl_disconnect() flush all recv_work() and release the<br /> initial reference:<br /> <br /> nbd_genl_disconnect<br /> nbd_disconnect_and_put<br /> nbd_disconnect<br /> flush_workqueue(nbd-&gt;recv_workq)<br /> if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))<br /> nbd_config_put<br /> -&gt; due to step 1), reference is still not zero<br /> <br /> 3) nbd_genl_reconfigure() queue recv_work() again;<br /> <br /> nbd_genl_reconfigure<br /> config = nbd_get_config_unlocked(nbd)<br /> if (!config)<br /> -&gt; succeed<br /> if (!test_bit(NBD_RT_BOUND, ...))<br /> -&gt; succeed<br /> nbd_reconnect_socket<br /> queue_work(nbd-&gt;recv_workq, &amp;args-&gt;work)<br /> <br /> 4) step 1) release the reference;<br /> <br /> 5) Finially, recv_work() will trigger UAF:<br /> <br /> recv_work<br /> nbd_config_put(nbd)<br /> -&gt; nbd_config is freed<br /> atomic_dec(&amp;config-&gt;recv_threads)<br /> -&gt; UAF<br /> <br /> Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so<br /> that nbd_genl_reconfigure() will fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix implicit ODP use after free<br /> <br /> Prevent double queueing of implicit ODP mr destroy work by using<br /> __xa_cmpxchg() to make sure this is the only time we are destroying this<br /> specific mr.<br /> <br /> Without this change, we could try to invalidate this mr twice, which in<br /> turn could result in queuing a MR work destroy twice, and eventually the<br /> second work could execute after the MR was freed due to the first work,<br /> causing a user after free and trace below.<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130<br /> Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs]<br /> CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib]<br /> RIP: 0010:refcount_warn_saturate+0x12b/0x130<br /> Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff<br /> RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027<br /> RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0<br /> RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019<br /> R10: 000000000000072e R11: 0000000063666572 R12: ffff88812bfd9e00<br /> R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0<br /> FS: 0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? refcount_warn_saturate+0x12b/0x130<br /> free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib]<br /> process_one_work+0x1cc/0x3c0<br /> worker_thread+0x218/0x3c0<br /> kthread+0xc6/0xf0<br /> ret_from_fork+0x1f/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: add missing cpu_to_node to kvzalloc_node in mlx5e_open_xdpredirect_sq<br /> <br /> kvzalloc_node is not doing a runtime check on the node argument<br /> (__alloc_pages_node_noprof does have a VM_BUG_ON, but it expands to<br /> nothing on !CONFIG_DEBUG_VM builds), so doing any ethtool/netlink<br /> operation that calls mlx5e_open on a CPU that&amp;#39;s larger that MAX_NUMNODES<br /> triggers OOB access and panic (see the trace below).<br /> <br /> Add missing cpu_to_node call to convert cpu id to node id.<br /> <br /> [ 165.427394] mlx5_core 0000:5c:00.0 beth1: Link up<br /> [ 166.479327] BUG: unable to handle page fault for address: 0000000800000010<br /> [ 166.494592] #PF: supervisor read access in kernel mode<br /> [ 166.505995] #PF: error_code(0x0000) - not-present page<br /> ...<br /> [ 166.816958] Call Trace:<br /> [ 166.822380] <br /> [ 166.827034] ? __die_body+0x64/0xb0<br /> [ 166.834774] ? page_fault_oops+0x2cd/0x3f0<br /> [ 166.843862] ? exc_page_fault+0x63/0x130<br /> [ 166.852564] ? asm_exc_page_fault+0x22/0x30<br /> [ 166.861843] ? __kvmalloc_node_noprof+0x43/0xd0<br /> [ 166.871897] ? get_partial_node+0x1c/0x320<br /> [ 166.880983] ? deactivate_slab+0x269/0x2b0<br /> [ 166.890069] ___slab_alloc+0x521/0xa90<br /> [ 166.898389] ? __kvmalloc_node_noprof+0x43/0xd0<br /> [ 166.908442] __kmalloc_node_noprof+0x216/0x3f0<br /> [ 166.918302] ? __kvmalloc_node_noprof+0x43/0xd0<br /> [ 166.928354] __kvmalloc_node_noprof+0x43/0xd0<br /> [ 166.938021] mlx5e_open_channels+0x5e2/0xc00<br /> [ 166.947496] mlx5e_open_locked+0x3e/0xf0<br /> [ 166.956201] mlx5e_open+0x23/0x50<br /> [ 166.963551] __dev_open+0x114/0x1c0<br /> [ 166.971292] __dev_change_flags+0xa2/0x1b0<br /> [ 166.980378] dev_change_flags+0x21/0x60<br /> [ 166.988887] do_setlink+0x38d/0xf20<br /> [ 166.996628] ? ep_poll_callback+0x1b9/0x240<br /> [ 167.005910] ? __nla_validate_parse.llvm.10713395753544950386+0x80/0xd70<br /> [ 167.020782] ? __wake_up_sync_key+0x52/0x80<br /> [ 167.030066] ? __mutex_lock+0xff/0x550<br /> [ 167.038382] ? security_capable+0x50/0x90<br /> [ 167.047279] rtnl_setlink+0x1c9/0x210<br /> [ 167.055403] ? ep_poll_callback+0x1b9/0x240<br /> [ 167.064684] ? security_capable+0x50/0x90<br /> [ 167.073579] rtnetlink_rcv_msg+0x2f9/0x310<br /> [ 167.082667] ? rtnetlink_bind+0x30/0x30<br /> [ 167.091173] netlink_rcv_skb+0xb1/0xe0<br /> [ 167.099492] netlink_unicast+0x20f/0x2e0<br /> [ 167.108191] netlink_sendmsg+0x389/0x420<br /> [ 167.116896] __sys_sendto+0x158/0x1c0<br /> [ 167.125024] __x64_sys_sendto+0x22/0x30<br /> [ 167.133534] do_syscall_64+0x63/0x130<br /> [ 167.141657] ? __irq_exit_rcu.llvm.17843942359718260576+0x52/0xd0<br /> [ 167.155181] entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: delete intermediate secpath entry in packet offload mode<br /> <br /> Packets handled by hardware have added secpath as a way to inform XFRM<br /> core code that this path was already handled. That secpath is not needed<br /> at all after policy is checked and it is removed later in the stack.<br /> <br /> However, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward),<br /> that secpath is not removed and packets which already were handled are reentered<br /> to the driver TX path with xfrm_offload set.<br /> <br /> The following kernel panic is observed in mlx5 in such case:<br /> <br /> mlx5_core 0000:04:00.0 enp4s0f0np0: Link up<br /> mlx5_core 0000:04:00.1 enp4s0f1np1: Link up<br /> Initializing XFRM netlink socket<br /> IPsec XFRM device driver<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor instruction fetch in kernel mode<br /> #PF: error_code(0x0010) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0010 [#1] PREEMPT SMP<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 0018:ffffb87380003800 EFLAGS: 00010206<br /> RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf<br /> RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00<br /> RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010<br /> R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00<br /> R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e<br /> FS: 0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> ? show_regs+0x63/0x70<br /> ? __die_body+0x20/0x60<br /> ? __die+0x2b/0x40<br /> ? page_fault_oops+0x15c/0x550<br /> ? do_user_addr_fault+0x3ed/0x870<br /> ? exc_page_fault+0x7f/0x190<br /> ? asm_exc_page_fault+0x27/0x30<br /> mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core]<br /> mlx5e_xmit+0x58e/0x1980 [mlx5_core]<br /> ? __fib_lookup+0x6a/0xb0<br /> dev_hard_start_xmit+0x82/0x1d0<br /> sch_direct_xmit+0xfe/0x390<br /> __dev_queue_xmit+0x6d8/0xee0<br /> ? __fib_lookup+0x6a/0xb0<br /> ? internal_add_timer+0x48/0x70<br /> ? mod_timer+0xe2/0x2b0<br /> neigh_resolve_output+0x115/0x1b0<br /> __neigh_update+0x26a/0xc50<br /> neigh_update+0x14/0x20<br /> arp_process+0x2cb/0x8e0<br /> ? __napi_build_skb+0x5e/0x70<br /> arp_rcv+0x11e/0x1c0<br /> ? dev_gro_receive+0x574/0x820<br /> __netif_receive_skb_list_core+0x1cf/0x1f0<br /> netif_receive_skb_list_internal+0x183/0x2a0<br /> napi_complete_done+0x76/0x1c0<br /> mlx5e_napi_poll+0x234/0x7a0 [mlx5_core]<br /> __napi_poll+0x2d/0x1f0<br /> net_rx_action+0x1a6/0x370<br /> ? atomic_notifier_call_chain+0x3b/0x50<br /> ? irq_int_handler+0x15/0x20 [mlx5_core]<br /> handle_softirqs+0xb9/0x2f0<br /> ? handle_irq_event+0x44/0x60<br /> irq_exit_rcu+0xdb/0x100<br /> common_interrupt+0x98/0xc0<br /> <br /> <br /> asm_common_interrupt+0x27/0x40<br /> RIP: 0010:pv_native_safe_halt+0xb/0x10<br /> Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22<br /> 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb<br /> 40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8<br /> RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680<br /> RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4<br /> RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70<br /> R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8<br /> ? default_idle+0x9/0x20<br /> arch_cpu_idle+0x9/0x10<br /> default_idle_call+0x29/0xf0<br /> do_idle+0x1f2/0x240<br /> cpu_startup_entry+0x2c/0x30<br /> rest_init+0xe7/0x100<br /> start_kernel+0x76b/0xb90<br /> x86_64_start_reservations+0x18/0x30<br /> x86_64_start_kernel+0xc0/0x110<br /> ? setup_ghcb+0xe/0x130<br /> common_startup_64+0x13e/0x141<br /> <br /> Modules linked in: esp4_offload esp4 xfrm_interface<br /> xfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binf<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix possible crash when setting up bsg fails<br /> <br /> If bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value.<br /> Consequently, in mpi3mr_bsg_exit(), the condition "if(!mrioc-&gt;bsg_queue)"<br /> will not be satisfied, preventing execution from entering<br /> bsg_remove_queue(), which could lead to the following crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000041c<br /> Call Trace:<br /> <br /> mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr]<br /> mpi3mr_remove+0x6f/0x340 [mpi3mr]<br /> pci_device_remove+0x3f/0xb0<br /> device_release_driver_internal+0x19d/0x220<br /> unbind_store+0xa4/0xb0<br /> kernfs_fop_write_iter+0x11f/0x200<br /> vfs_write+0x1fc/0x3e0<br /> ksys_write+0x67/0xe0<br /> do_syscall_64+0x38/0x80<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: davicom: fix UAF in dm9000_drv_remove<br /> <br /> dm is netdev private data and it cannot be<br /> used after free_netdev() call. Using dm after free_netdev()<br /> can cause UAF bug. Fix it by moving free_netdev() at the end of the<br /> function.<br /> <br /> This is similar to the issue fixed in commit<br /> ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").<br /> <br /> This bug is detected by our static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix uninit-value in vxlan_vnifilter_dump()<br /> <br /> KMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1].<br /> <br /> If the length of the netlink message payload is less than<br /> sizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes<br /> beyond the message. This can lead to uninit-value access. Fix this by<br /> returning an error in such situations.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422<br /> vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422<br /> rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786<br /> netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317<br /> __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432<br /> netlink_dump_start include/linux/netlink.h:340 [inline]<br /> rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline]<br /> rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882<br /> netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542<br /> rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]<br /> netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347<br /> netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x330/0x3d0 net/socket.c:726<br /> ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637<br /> __sys_sendmsg net/socket.c:2669 [inline]<br /> __do_sys_sendmsg net/socket.c:2674 [inline]<br /> __se_sys_sendmsg net/socket.c:2672 [inline]<br /> __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672<br /> x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4110 [inline]<br /> slab_alloc_node mm/slub.c:4153 [inline]<br /> kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205<br /> kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587<br /> __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678<br /> alloc_skb include/linux/skbuff.h:1323 [inline]<br /> netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196<br /> netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x330/0x3d0 net/socket.c:726<br /> ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637<br /> __sys_sendmsg net/socket.c:2669 [inline]<br /> __do_sys_sendmsg net/socket.c:2674 [inline]<br /> __se_sys_sendmsg net/socket.c:2672 [inline]<br /> __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672<br /> x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> CPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rose: fix timer races against user threads<br /> <br /> Rose timers only acquire the socket spinlock, without<br /> checking if the socket is owned by one user thread.<br /> <br /> Add a check and rearm the timers if needed.<br /> <br /> BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174<br /> Read of size 2 at addr ffff88802f09b82a by task swapper/0/0<br /> <br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:489<br /> kasan_report+0x143/0x180 mm/kasan/report.c:602<br /> rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174<br /> call_timer_fn+0x187/0x650 kernel/time/timer.c:1793<br /> expire_timers kernel/time/timer.c:1844 [inline]<br /> __run_timers kernel/time/timer.c:2418 [inline]<br /> __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430<br /> run_timer_base kernel/time/timer.c:2439 [inline]<br /> run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449<br /> handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561<br /> __do_softirq kernel/softirq.c:595 [inline]<br /> invoke_softirq kernel/softirq.c:435 [inline]<br /> __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662<br /> irq_exit_rcu+0x9/0x30 kernel/softirq.c:678<br /> instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]<br /> sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmr: do not call mr_mfc_uses_dev() for unres entries<br /> <br /> syzbot found that calling mr_mfc_uses_dev() for unres entries<br /> would crash [1], because c-&gt;mfc_un.res.minvif / c-&gt;mfc_un.res.maxvif<br /> alias to "struct sk_buff_head unresolved", which contain two pointers.<br /> <br /> This code never worked, lets remove it.<br /> <br /> [1]<br /> Unable to handle kernel paging request at virtual address ffff5fff2d536613<br /> KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline]<br /> pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334<br /> lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline]<br /> lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334<br /> Call trace:<br /> mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P)<br /> mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P)<br /> mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382<br /> ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648<br /> rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327<br /> rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791<br /> netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317<br /> netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973<br /> sock_recvmsg_nosec net/socket.c:1033 [inline]<br /> sock_recvmsg net/socket.c:1055 [inline]<br /> sock_read_iter+0x2d8/0x40c net/socket.c:1125<br /> new_sync_read fs/read_write.c:484 [inline]<br /> vfs_read+0x740/0x970 fs/read_write.c:565<br /> ksys_read+0x15c/0x26c fs/read_write.c:708