Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: avoid to init mgnt_entry list twice when WoWLAN failed<br /> <br /> If WoWLAN failed in resume flow, the rtw89_ops_add_interface() triggered<br /> without removing the interface first. Then the mgnt_entry list init again,<br /> causing the list_empty() check in rtw89_chanctx_ops_assign_vif()<br /> useless, and list_add_tail() again. Therefore, we have added a check to<br /> prevent double adding of the list.<br /> <br /> rtw89_8852ce 0000:01:00.0: failed to check wow status disabled<br /> rtw89_8852ce 0000:01:00.0: wow: failed to check disable fw ready<br /> rtw89_8852ce 0000:01:00.0: wow: failed to swap to normal fw<br /> rtw89_8852ce 0000:01:00.0: failed to disable wow<br /> rtw89_8852ce 0000:01:00.0: failed to resume for wow -110<br /> rtw89_8852ce 0000:01:00.0: MAC has already powered on<br /> i2c_hid_acpi i2c-ILTK0001:00: PM: acpi_subsys_resume+0x0/0x60 returned 0 after 284705 usecs<br /> list_add corruption. prev-&gt;next should be next (ffff9d9719d82228), but was ffff9d9719f96030. (prev=ffff9d9719f96030).<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:34!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 2 PID: 6918 Comm: kworker/u8:19 Tainted: G U O<br /> Hardware name: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.514.0 03/25/2024<br /> Workqueue: events_unbound async_run_entry_fn<br /> RIP: 0010:__list_add_valid_or_report+0x9f/0xb0<br /> Code: e8 56 89 ff ff 0f 0b 48 c7 c7 3e fc e0 96 48 89 c6 e8 45 89 ff ...<br /> RSP: 0018:ffffa51b42bbbaf0 EFLAGS: 00010246<br /> RAX: 0000000000000075 RBX: ffff9d9719d82ab0 RCX: 13acb86e047a4400<br /> RDX: 3fffffffffffffff RSI: 0000000000000000 RDI: 00000000ffffdfff<br /> RBP: ffffa51b42bbbb28 R08: ffffffff9768e250 R09: 0000000000001fff<br /> R10: ffffffff9765e250 R11: 0000000000005ffd R12: ffff9d9719f95c40<br /> R13: ffff9d9719f95be8 R14: ffff9d97081bfd78 R15: ffff9d9719d82060<br /> FS: 0000000000000000(0000) GS:ffff9d9a6fb00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007e7d029a4060 CR3: 0000000345e38000 CR4: 0000000000750ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body+0x68/0xb0<br /> ? die+0xaa/0xd0<br /> ? do_trap+0x9f/0x170<br /> ? __list_add_valid_or_report+0x9f/0xb0<br /> ? __list_add_valid_or_report+0x9f/0xb0<br /> ? handle_invalid_op+0x69/0x90<br /> ? __list_add_valid_or_report+0x9f/0xb0<br /> ? exc_invalid_op+0x3c/0x50<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? __list_add_valid_or_report+0x9f/0xb0<br /> rtw89_chanctx_ops_assign_vif+0x1f9/0x210 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1]<br /> ? __mutex_unlock_slowpath+0xa0/0xf0<br /> rtw89_ops_assign_vif_chanctx+0x4b/0x90 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1]<br /> drv_assign_vif_chanctx+0xa7/0x1f0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6]<br /> ieee80211_reconfig+0x9cb/0x17b0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6]<br /> ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]<br /> ? dev_printk_emit+0x51/0x70<br /> ? _dev_info+0x6e/0x90<br /> wiphy_resume+0x89/0x180 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]<br /> ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]<br /> dpm_run_callback+0x37/0x1e0<br /> device_resume+0x26d/0x4b0<br /> ? __pfx_dpm_watchdog_handler+0x10/0x10<br /> async_resume+0x1d/0x30<br /> async_run_entry_fn+0x29/0xd0<br /> worker_thread+0x397/0x970<br /> kthread+0xed/0x110<br /> ? __pfx_worker_thread+0x10/0x10<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x38/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br />

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 /> iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()<br /> <br /> Resolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index()<br /> where shifting the constant "1" (of type int) by bitmap-&gt;mapped.pgshift<br /> (an unsigned long value) could result in undefined behavior.<br /> <br /> The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds<br /> 31 (e.g., pgshift = 63) the shift operation overflows, as the result<br /> cannot be represented in a 32-bit type.<br /> <br /> To resolve this, the constant is updated to "1UL", promoting it to an<br /> unsigned long type to match the operand&amp;#39;s type.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix oops due to unset link speed<br /> <br /> It isn&amp;#39;t guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always<br /> be set by the server, so the client must handle any values and then<br /> prevent oopses like below from happening:<br /> <br /> Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41<br /> 04/01/2014<br /> RIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48<br /> 89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8<br /> e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 f7 74 24 18 48 89<br /> c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24<br /> RSP: 0018:ffffc90001817be0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99<br /> RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228<br /> RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac<br /> R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200<br /> R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58<br /> FS: 00007fe27119e740(0000) GS:ffff888148600000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? die+0x2e/0x50<br /> ? do_trap+0x159/0x1b0<br /> ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]<br /> ? do_error_trap+0x90/0x130<br /> ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]<br /> ? exc_divide_error+0x39/0x50<br /> ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]<br /> ? asm_exc_divide_error+0x1a/0x20<br /> ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs]<br /> ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]<br /> ? seq_read_iter+0x42e/0x790<br /> seq_read_iter+0x19a/0x790<br /> proc_reg_read_iter+0xbe/0x110<br /> ? __pfx_proc_reg_read_iter+0x10/0x10<br /> vfs_read+0x469/0x570<br /> ? do_user_addr_fault+0x398/0x760<br /> ? __pfx_vfs_read+0x10/0x10<br /> ? find_held_lock+0x8a/0xa0<br /> ? __pfx_lock_release+0x10/0x10<br /> ksys_read+0xd3/0x170<br /> ? __pfx_ksys_read+0x10/0x10<br /> ? __rcu_read_unlock+0x50/0x270<br /> ? mark_held_locks+0x1a/0x90<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fe271288911<br /> Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8<br /> 20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 3d<br /> 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec<br /> RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911<br /> RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003<br /> RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380<br /> R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000<br /> R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000<br /> <br /> <br /> Fix this by setting cifs_server_iface::speed to a sane value (1Gbps)<br /> by default when link speed is unset.

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