Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: handle errors that nilfs_prepare_chunk() may return<br /> <br /> Patch series "nilfs2: fix issues with rename operations".<br /> <br /> This series fixes BUG_ON check failures reported by syzbot around rename<br /> operations, and a minor behavioral issue where the mtime of a child<br /> directory changes when it is renamed instead of moved.<br /> <br /> <br /> This patch (of 2):<br /> <br /> The directory manipulation routines nilfs_set_link() and<br /> nilfs_delete_entry() rewrite the directory entry in the folio/page<br /> previously read by nilfs_find_entry(), so error handling is omitted on the<br /> assumption that nilfs_prepare_chunk(), which prepares the buffer for<br /> rewriting, will always succeed for these. And if an error is returned, it<br /> triggers the legacy BUG_ON() checks in each routine.<br /> <br /> This assumption is wrong, as proven by syzbot: the buffer layer called by<br /> nilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may<br /> fail due to metadata corruption or other reasons. This has been there all<br /> along, but improved sanity checks and error handling may have made it more<br /> reproducible in fuzzing tests.<br /> <br /> Fix this issue by adding missing error paths in nilfs_set_link(),<br /> nilfs_delete_entry(), and their caller nilfs_rename().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: do not force clear folio if buffer is referenced<br /> <br /> Patch series "nilfs2: protect busy buffer heads from being force-cleared".<br /> <br /> This series fixes the buffer head state inconsistency issues reported by<br /> syzbot that occurs when the filesystem is corrupted and falls back to<br /> read-only, and the associated buffer head use-after-free issue.<br /> <br /> <br /> This patch (of 2):<br /> <br /> Syzbot has reported that after nilfs2 detects filesystem corruption and<br /> falls back to read-only, inconsistencies in the buffer state may occur.<br /> <br /> One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()<br /> to set a data or metadata buffer as dirty, but it detects that the buffer<br /> is not in the uptodate state:<br /> <br /> WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520<br /> fs/buffer.c:1177<br /> ...<br /> Call Trace:<br /> <br /> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598<br /> nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73<br /> nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344<br /> nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218<br /> vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257<br /> do_mkdirat+0x264/0x3a0 fs/namei.c:4280<br /> __do_sys_mkdirat fs/namei.c:4295 [inline]<br /> __se_sys_mkdirat fs/namei.c:4293 [inline]<br /> __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293<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<br /> <br /> The other is when nilfs_btree_propagate(), which propagates the dirty<br /> state to the ancestor nodes of a b-tree that point to a dirty buffer,<br /> detects that the origin buffer is not dirty, even though it should be:<br /> <br /> WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089<br /> nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089<br /> ...<br /> Call Trace:<br /> <br /> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345<br /> nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587<br /> nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006<br /> nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045<br /> nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]<br /> nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]<br /> nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115<br /> nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479<br /> nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]<br /> nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> Both of these issues are caused by the callbacks that handle the<br /> page/folio write requests, forcibly clear various states, including the<br /> working state of the buffers they hold, at unexpected times when they<br /> detect read-only fallback.<br /> <br /> Fix these issues by checking if the buffer is referenced before clearing<br /> the page/folio state, and skipping the clear if it is.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: prevent reg-wait speculations<br /> <br /> With *ENTER_EXT_ARG_REG instead of passing a user pointer with arguments<br /> for the waiting loop the user can specify an offset into a pre-mapped<br /> region of memory, in which case the<br /> [offset, offset + sizeof(io_uring_reg_wait)) will be intepreted as the<br /> argument.<br /> <br /> As we address a kernel array using a user given index, it&amp;#39;d be a subject<br /> to speculation type of exploits. Use array_index_nospec() to prevent<br /> that. Make sure to pass not the full region size but truncate by the<br /> maximum offset allowed considering the structure size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries/iommu: Don&amp;#39;t unset window if it was never set<br /> <br /> On pSeries, when user attempts to use the same vfio container used by<br /> different iommu group, the spapr_tce_set_window() returns -EPERM<br /> and the subsequent cleanup leads to the below crash.<br /> <br /> Kernel attempted to read user page (308) - exploit attempt?<br /> BUG: Kernel NULL pointer dereference on read at 0x00000308<br /> Faulting instruction address: 0xc0000000001ce358<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> NIP: c0000000001ce358 LR: c0000000001ce05c CTR: c00000000005add0<br /> <br /> NIP [c0000000001ce358] spapr_tce_unset_window+0x3b8/0x510<br /> LR [c0000000001ce05c] spapr_tce_unset_window+0xbc/0x510<br /> Call Trace:<br /> spapr_tce_unset_window+0xbc/0x510 (unreliable)<br /> tce_iommu_attach_group+0x24c/0x340 [vfio_iommu_spapr_tce]<br /> vfio_container_attach_group+0xec/0x240 [vfio]<br /> vfio_group_fops_unl_ioctl+0x548/0xb00 [vfio]<br /> sys_ioctl+0x754/0x1580<br /> system_call_exception+0x13c/0x330<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> --- interrupt: 3000<br /> <br /> Fix this by having null check for the tbl passed to the<br /> spapr_tce_unset_window().