Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: bnxt: always recalculate features after XDP clearing, fix null-deref<br /> <br /> Recalculate features when XDP is detached.<br /> <br /> Before:<br /> # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp<br /> # ip li set dev eth0 xdp off<br /> # ethtool -k eth0 | grep gro<br /> rx-gro-hw: off [requested on]<br /> <br /> After:<br /> # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp<br /> # ip li set dev eth0 xdp off<br /> # ethtool -k eth0 | grep gro<br /> rx-gro-hw: on<br /> <br /> The fact that HW-GRO doesn&amp;#39;t get re-enabled automatically is just<br /> a minor annoyance. The real issue is that the features will randomly<br /> come back during another reconfiguration which just happens to invoke<br /> netdev_update_features(). The driver doesn&amp;#39;t handle reconfiguring<br /> two things at a time very robustly.<br /> <br /> Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in<br /> __bnxt_reserve_rings()") we only reconfigure the RSS hash table<br /> if the "effective" number of Rx rings has changed. If HW-GRO is<br /> enabled "effective" number of rings is 2x what user sees.<br /> So if we are in the bad state, with HW-GRO re-enablement "pending"<br /> after XDP off, and we lower the rings by / 2 - the HW-GRO rings<br /> doing 2x and the ethtool -L doing / 2 may cancel each other out,<br /> and the:<br /> <br /> if (old_rx_rings != bp-&gt;hw_resc.resv_rx_rings &amp;&amp;<br /> <br /> condition in __bnxt_reserve_rings() will be false.<br /> The RSS map won&amp;#39;t get updated, and we&amp;#39;ll crash with:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000168<br /> RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0<br /> bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180<br /> __bnxt_setup_vnic_p5+0x58/0x110<br /> bnxt_init_nic+0xb72/0xf50<br /> __bnxt_open_nic+0x40d/0xab0<br /> bnxt_open_nic+0x2b/0x60<br /> ethtool_set_channels+0x18c/0x1d0<br /> <br /> As we try to access a freed ring.<br /> <br /> The issue is present since XDP support was added, really, but<br /> prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in<br /> __bnxt_reserve_rings()") it wasn&amp;#39;t causing major issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pktgen: Avoid out-of-bounds access in get_imix_entries<br /> <br /> Passing a sufficient amount of imix entries leads to invalid access to the<br /> pkt_dev-&gt;imix_entries array because of the incorrect boundary check.<br /> <br /> UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24<br /> index 20 is out of range for type &amp;#39;imix_pkt [20]&amp;#39;<br /> CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Call Trace:<br /> <br /> dump_stack_lvl lib/dump_stack.c:117<br /> __ubsan_handle_out_of_bounds lib/ubsan.c:429<br /> get_imix_entries net/core/pktgen.c:874<br /> pktgen_if_write net/core/pktgen.c:1063<br /> pde_write fs/proc/inode.c:334<br /> proc_reg_write fs/proc/inode.c:346<br /> vfs_write fs/read_write.c:593<br /> ksys_write fs/read_write.c:644<br /> do_syscall_64 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> [ fp: allow to fill the array completely; minor changelog cleanup ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: fix lockup on tx to unregistering netdev with carrier<br /> <br /> Commit in a fixes tag attempted to fix the issue in the following<br /> sequence of calls:<br /> <br /> do_output<br /> -&gt; ovs_vport_send<br /> -&gt; dev_queue_xmit<br /> -&gt; __dev_queue_xmit<br /> -&gt; netdev_core_pick_tx<br /> -&gt; skb_tx_hash<br /> <br /> When device is unregistering, the &amp;#39;dev-&gt;real_num_tx_queues&amp;#39; goes to<br /> zero and the &amp;#39;while (unlikely(hash &gt;= qcount))&amp;#39; loop inside the<br /> &amp;#39;skb_tx_hash&amp;#39; becomes infinite, locking up the core forever.<br /> <br /> But unfortunately, checking just the carrier status is not enough to<br /> fix the issue, because some devices may still be in unregistering<br /> state while reporting carrier status OK.<br /> <br /> One example of such device is a net/dummy. It sets carrier ON<br /> on start, but it doesn&amp;#39;t implement .ndo_stop to set the carrier off.<br /> And it makes sense, because dummy doesn&amp;#39;t really have a carrier.<br /> Therefore, while this device is unregistering, it&amp;#39;s still easy to hit<br /> the infinite loop in the skb_tx_hash() from the OVS datapath. There<br /> might be other drivers that do the same, but dummy by itself is<br /> important for the OVS ecosystem, because it is frequently used as a<br /> packet sink for tcpdump while debugging OVS deployments. And when the<br /> issue is hit, the only way to recover is to reboot.<br /> <br /> Fix that by also checking if the device is running. The running<br /> state is handled by the net core during unregistering, so it covers<br /> unregistering case better, and we don&amp;#39;t really need to send packets<br /> to devices that are not running anyway.<br /> <br /> While only checking the running state might be enough, the carrier<br /> check is preserved. The running and the carrier states seem disjoined<br /> throughout the code and different drivers. And other core functions<br /> like __dev_direct_xmit() check both before attempting to transmit<br /> a packet. So, it seems safer to check both flags in OVS as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix merge preference rule failure condition<br /> <br /> syzbot reported a lock held when returning to userspace[1]. This is<br /> because if argc is less than 0 and the function returns directly, the held<br /> inode lock is not released.<br /> <br /> Fix this by store the error in ret and jump to done to clean up instead of<br /> returning directly.<br /> <br /> [dh: Modified Lizhi Xu&amp;#39;s original patch to make it honour the error code<br /> from afs_split_string()]<br /> <br /> [1]<br /> WARNING: lock held when returning to user space!<br /> 6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Not tainted<br /> ------------------------------------------------<br /> syz-executor133/5823 is leaving the kernel with locks still held!<br /> 1 lock held by syz-executor133/5823:<br /> #0: ffff888071cffc00 (&amp;sb-&gt;s_type-&gt;i_mutex_key#9){++++}-{4:4}, at: inode_lock include/linux/fs.h:818 [inline]<br /> #0: ffff888071cffc00 (&amp;sb-&gt;s_type-&gt;i_mutex_key#9){++++}-{4:4}, at: afs_proc_addr_prefs_write+0x2bb/0x14e0 fs/afs/addr_prefs.c:388

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pfcp: Destroy device along with udp socket&amp;#39;s netns dismantle.<br /> <br /> pfcp_newlink() links the device to a list in dev_net(dev) instead<br /> of net, where a udp tunnel socket is created.<br /> <br /> Even when net is removed, the device stays alive on dev_net(dev).<br /> Then, removing net triggers the splat below. [0]<br /> <br /> In this example, pfcp0 is created in ns2, but the udp socket is<br /> created in ns1.<br /> <br /> ip netns add ns1<br /> ip netns add ns2<br /> ip -n ns1 link add netns ns2 name pfcp0 type pfcp<br /> ip netns del ns1<br /> <br /> Let&amp;#39;s link the device to the socket&amp;#39;s netns instead.<br /> <br /> Now, pfcp_net_exit() needs another netdev iteration to remove<br /> all pfcp devices in the netns.<br /> <br /> pfcp_dev_list is not used under RCU, so the list API is converted<br /> to the non-RCU variant.<br /> <br /> pfcp_net_exit() can be converted to .exit_batch_rtnl() in net-next.<br /> <br /> [0]:<br /> ref_tracker: net notrefcnt@00000000128b34dc has 1/1 users at<br /> sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)<br /> inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)<br /> __sock_create (net/socket.c:1558)<br /> udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)<br /> pfcp_create_sock (drivers/net/pfcp.c:168)<br /> pfcp_newlink (drivers/net/pfcp.c:182 drivers/net/pfcp.c:197)<br /> rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2542)<br /> netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1891)<br /> ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)<br /> ___sys_sendmsg (net/socket.c:2639)<br /> __sys_sendmsg (net/socket.c:2669)<br /> do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> WARNING: CPU: 1 PID: 11 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89<br /> RSP: 0018:ff11000007f3fb60 EFLAGS: 00010286<br /> RAX: 00000000000020ef RBX: ff1100000d6481e0 RCX: 1ffffffff0e40d82<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c<br /> RBP: ff1100000d648230 R08: 0000000000000001 R09: fffffbfff0e395af<br /> R10: 0000000000000001 R11: 0000000000000000 R12: ff1100000d648230<br /> R13: dead000000000100 R14: ff1100000d648230 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005620e1363990 CR3: 000000000eeb2002 CR4: 0000000000771ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn (kernel/panic.c:748)<br /> ? ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> ? report_bug (lib/bug.c:201 lib/bug.c:219)<br /> ? handle_bug (arch/x86/kernel/traps.c:285)<br /> ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))<br /> ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)<br /> ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)<br /> ? ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)<br /> ? kfree (mm/slub.c:4613 mm/slub.c:4761)<br /> net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)<br /> cleanup_net (net/cor<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: Destroy device along with udp socket&amp;#39;s netns dismantle.<br /> <br /> gtp_newlink() links the device to a list in dev_net(dev) instead of<br /> src_net, where a udp tunnel socket is created.<br /> <br /> Even when src_net is removed, the device stays alive on dev_net(dev).<br /> Then, removing src_net triggers the splat below. [0]<br /> <br /> In this example, gtp0 is created in ns2, and the udp socket is created<br /> in ns1.<br /> <br /> ip netns add ns1<br /> ip netns add ns2<br /> ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn<br /> ip netns del ns1<br /> <br /> Let&amp;#39;s link the device to the socket&amp;#39;s netns instead.<br /> <br /> Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove<br /> all gtp devices in the netns.<br /> <br /> [0]:<br /> ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at<br /> sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)<br /> inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)<br /> __sock_create (net/socket.c:1558)<br /> udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)<br /> gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)<br /> gtp_create_sockets (drivers/net/gtp.c:1447)<br /> gtp_newlink (drivers/net/gtp.c:1507)<br /> rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2542)<br /> netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1891)<br /> ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)<br /> ___sys_sendmsg (net/socket.c:2639)<br /> __sys_sendmsg (net/socket.c:2669)<br /> do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)<br /> <br /> WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89<br /> RSP: 0018:ff11000009a07b60 EFLAGS: 00010286<br /> RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c<br /> RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae<br /> R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0<br /> R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn (kernel/panic.c:748)<br /> ? ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> ? report_bug (lib/bug.c:201 lib/bug.c:219)<br /> ? handle_bug (arch/x86/kernel/traps.c:285)<br /> ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))<br /> ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)<br /> ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)<br /> ? ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)<br /> ? kfree (mm/slub.c:4613 mm/slub.c:4761)<br /> net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)<br /> cleanup_net (net/core/net_namespace.c:664 (discriminator 3))<br /> process_one_work (kernel/workqueue.c:3229)<br /> worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fec: handle page_pool_dev_alloc_pages error<br /> <br /> The fec_enet_update_cbd function calls page_pool_dev_alloc_pages but did<br /> not handle the case when it returned NULL. There was a WARN_ON(!new_page)<br /> but it would still proceed to use the NULL pointer and then crash.<br /> <br /> This case does seem somewhat rare but when the system is under memory<br /> pressure it can happen. One case where I can duplicate this with some<br /> frequency is when writing over a smbd share to a SATA HDD attached to an<br /> imx6q.<br /> <br /> Setting /proc/sys/vm/min_free_kbytes to higher values also seems to solve<br /> the problem for my test case. But it still seems wrong that the fec driver<br /> ignores the memory allocation error and can crash.<br /> <br /> This commit handles the allocation error by dropping the current packet.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Clear port select structure when fail to create<br /> <br /> Clear the port select structure on error so no stale values left after<br /> definers are destroyed. That&amp;#39;s because the mlx5_lag_destroy_definers()<br /> always try to destroy all lag definers in the tt_map, so in the flow<br /> below lag definers get double-destroyed and cause kernel crash:<br /> <br /> mlx5_lag_port_sel_create()<br /> mlx5_lag_create_definers()<br /> mlx5_lag_create_definer()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel<br /> <br /> Attempt to enable IPsec packet offload in tunnel mode in debug kernel<br /> generates the following kernel panic, which is happening due to two<br /> issues:<br /> 1. In SA add section, the should be _bh() variant when marking SA mode.<br /> 2. There is not needed flush_workqueue in SA delete routine. It is not<br /> needed as at this stage as it is removed from SADB and the running work<br /> will be canceled later in SA free.<br /> <br /> =====================================================<br /> WARNING: SOFTIRQ-safe -&gt; SOFTIRQ-unsafe lock order detected<br /> 6.12.0+ #4 Not tainted<br /> -----------------------------------------------------<br /> charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:<br /> ffff88810f365020 (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]<br /> <br /> and this task is already holding:<br /> ffff88813e0f0d48 (&amp;x-&gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30<br /> which would create a new lock dependency:<br /> (&amp;x-&gt;lock){+.-.}-{3:3} -&gt; (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}<br /> <br /> but this new dependency connects a SOFTIRQ-irq-safe lock:<br /> (&amp;x-&gt;lock){+.-.}-{3:3}<br /> <br /> ... which became SOFTIRQ-irq-safe at:<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock_bh+0x34/0x40<br /> xfrm_timer_handler+0x91/0xd70<br /> __hrtimer_run_queues+0x1dd/0xa60<br /> hrtimer_run_softirq+0x146/0x2e0<br /> handle_softirqs+0x266/0x860<br /> irq_exit_rcu+0x115/0x1a0<br /> sysvec_apic_timer_interrupt+0x6e/0x90<br /> asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> default_idle+0x13/0x20<br /> default_idle_call+0x67/0xa0<br /> do_idle+0x2da/0x320<br /> cpu_startup_entry+0x50/0x60<br /> start_secondary+0x213/0x2a0<br /> common_startup_64+0x129/0x138<br /> <br /> to a SOFTIRQ-irq-unsafe lock:<br /> (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}<br /> <br /> ... which became SOFTIRQ-irq-unsafe at:<br /> ...<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock+0x2c/0x40<br /> xa_set_mark+0x70/0x110<br /> mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core]<br /> xfrm_dev_state_add+0x3bb/0xd70<br /> xfrm_add_sa+0x2451/0x4a90<br /> xfrm_user_rcv_msg+0x493/0x880<br /> netlink_rcv_skb+0x12e/0x380<br /> xfrm_netlink_rcv+0x6d/0x90<br /> netlink_unicast+0x42f/0x740<br /> netlink_sendmsg+0x745/0xbe0<br /> __sock_sendmsg+0xc5/0x190<br /> __sys_sendto+0x1fe/0x2c0<br /> __x64_sys_sendto+0xdc/0x1b0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> other info that might help us debug this:<br /> <br /> Possible interrupt unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;xa-&gt;xa_lock#24);<br /> local_irq_disable();<br /> lock(&amp;x-&gt;lock);<br /> lock(&amp;xa-&gt;xa_lock#24);<br /> <br /> lock(&amp;x-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> 2 locks held by charon/1337:<br /> #0: ffffffff87f8f858 (&amp;net-&gt;xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90<br /> #1: ffff88813e0f0d48 (&amp;x-&gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30<br /> <br /> the dependencies between SOFTIRQ-irq-safe lock and the holding lock:<br /> -&gt; (&amp;x-&gt;lock){+.-.}-{3:3} ops: 29 {<br /> HARDIRQ-ON-W at:<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock_bh+0x34/0x40<br /> xfrm_alloc_spi+0xc0/0xe60<br /> xfrm_alloc_userspi+0x5f6/0xbc0<br /> xfrm_user_rcv_msg+0x493/0x880<br /> netlink_rcv_skb+0x12e/0x380<br /> xfrm_netlink_rcv+0x6d/0x90<br /> netlink_unicast+0x42f/0x740<br /> netlink_sendmsg+0x745/0xbe0<br /> __sock_sendmsg+0xc5/0x190<br /> __sys_sendto+0x1fe/0x2c0<br /> __x64_sys_sendto+0xdc/0x1b0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> IN-SOFTIRQ-W at:<br /> lock_acquire+0x1be/0x520<br /> _raw_spin_lock_bh+0x34/0x40<br /> xfrm_timer_handler+0x91/0xd70<br /> __hrtimer_run_queues+0x1dd/0xa60<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix double free of TCP_Server_Info::hostname<br /> <br /> When shutting down the server in cifs_put_tcp_session(), cifsd thread<br /> might be reconnecting to multiple DFS targets before it realizes it<br /> should exit the loop, so @server-&gt;hostname can&amp;#39;t be freed as long as<br /> cifsd thread isn&amp;#39;t done. Otherwise the following can happen:<br /> <br /> RIP: 0010:__slab_free+0x223/0x3c0<br /> Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89<br /> 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <br /> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80<br /> RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246<br /> RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068<br /> RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400<br /> RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500<br /> R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068<br /> FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000)<br /> 000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4:<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? show_trace_log_lvl+0x1c4/0x2df<br /> ? show_trace_log_lvl+0x1c4/0x2df<br /> ? __reconnect_target_unlocked+0x3e/0x160 [cifs]<br /> ? __die_body.cold+0x8/0xd<br /> ? die+0x2b/0x50<br /> ? do_trap+0xce/0x120<br /> ? __slab_free+0x223/0x3c0<br /> ? do_error_trap+0x65/0x80<br /> ? __slab_free+0x223/0x3c0<br /> ? exc_invalid_op+0x4e/0x70<br /> ? __slab_free+0x223/0x3c0<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? __slab_free+0x223/0x3c0<br /> ? extract_hostname+0x5c/0xa0 [cifs]<br /> ? extract_hostname+0x5c/0xa0 [cifs]<br /> ? __kmalloc+0x4b/0x140<br /> __reconnect_target_unlocked+0x3e/0x160 [cifs]<br /> reconnect_dfs_server+0x145/0x430 [cifs]<br /> cifs_handle_standard+0x1ad/0x1d0 [cifs]<br /> cifs_demultiplex_thread+0x592/0x730 [cifs]<br /> ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]<br /> kthread+0xdd/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x29/0x50<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/bpf: return early if transport is not assigned<br /> <br /> Some of the core functions can only be called if the transport<br /> has been assigned.<br /> <br /> As Michal reported, a socket might have the transport at NULL,<br /> for example after a failed connect(), causing the following trace:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000a0<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 12faf8067 P4D 12faf8067 PUD 113670067 PMD 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 15 UID: 0 PID: 1198 Comm: a.out Not tainted 6.13.0-rc2+<br /> RIP: 0010:vsock_connectible_has_data+0x1f/0x40<br /> Call Trace:<br /> vsock_bpf_recvmsg+0xca/0x5e0<br /> sock_recvmsg+0xb9/0xc0<br /> __sys_recvfrom+0xb3/0x130<br /> __x64_sys_recvfrom+0x20/0x30<br /> do_syscall_64+0x93/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> So we need to check the `vsk-&gt;transport` in vsock_bpf_recvmsg(),<br /> especially for connected sockets (stream/seqpacket) as we already<br /> do in __vsock_connectible_recvmsg().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: discard packets if the transport changes<br /> <br /> If the socket has been de-assigned or assigned to another transport,<br /> we must discard any packets received because they are not expected<br /> and would cause issues when we access vsk-&gt;transport.<br /> <br /> A possible scenario is described by Hyunwoo Kim in the attached link,<br /> where after a first connect() interrupted by a signal, and a second<br /> connect() failed, we can find `vsk-&gt;transport` at NULL, leading to a<br /> NULL pointer dereference.