Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zram: fix potential UAF of zram table<br /> <br /> If zram_meta_alloc failed early, it frees allocated zram-&gt;table without<br /> setting it NULL. Which will potentially cause zram_meta_free to access<br /> the table if user reset an failed and uninitialized device.

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 /> 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 /> mac802154: check local interfaces before deleting sdata list<br /> <br /> syzkaller reported a corrupted list in ieee802154_if_remove. [1]<br /> <br /> Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4<br /> hardware device from the system.<br /> <br /> CPU0 CPU1<br /> ==== ====<br /> genl_family_rcv_msg_doit ieee802154_unregister_hw<br /> ieee802154_del_iface ieee802154_remove_interfaces<br /> rdev_del_virtual_intf_deprecated list_del(&amp;sdata-&gt;list)<br /> ieee802154_if_remove<br /> list_del_rcu<br /> <br /> The net device has been unregistered, since the rcu grace period,<br /> unregistration must be run before ieee802154_if_remove.<br /> <br /> To avoid this issue, add a check for local-&gt;interfaces before deleting<br /> sdata list.<br /> <br /> [1]<br /> kernel BUG at lib/list_debug.c:58!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 Not tainted 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> RIP: 0010:__list_del_entry_valid_or_report+0xf4/0x140 lib/list_debug.c:56<br /> Code: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7<br /> RSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246<br /> RAX: 000000000000004e RBX: dead000000000122 RCX: d211eee56bb28d00<br /> RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000<br /> RBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d<br /> R10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000<br /> R13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0<br /> FS: 0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __list_del_entry_valid include/linux/list.h:124 [inline]<br /> __list_del_entry include/linux/list.h:215 [inline]<br /> list_del_rcu include/linux/rculist.h:157 [inline]<br /> ieee802154_if_remove+0x86/0x1e0 net/mac802154/iface.c:687<br /> rdev_del_virtual_intf_deprecated net/ieee802154/rdev-ops.h:24 [inline]<br /> ieee802154_del_iface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]<br /> genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2551<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]<br /> netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357<br /> netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901<br /> sock_sendmsg_nosec net/socket.c:729 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:744<br /> ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2607<br /> ___sys_sendmsg net/socket.c:2661 [inline]<br /> __sys_sendmsg+0x292/0x380 net/socket.c:2690<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> filemap: avoid truncating 64-bit offset to 32 bits<br /> <br /> On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a<br /> 64-bit value to 32 bits, leading to a possible infinite loop when writing<br /> to an xfs filesystem.