Vulnerabilities

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 /> kernel: be more careful about dup_mmap() failures and uprobe registering<br /> <br /> If a memory allocation fails during dup_mmap(), the maple tree can be left<br /> in an unsafe state for other iterators besides the exit path. All the<br /> locks are dropped before the exit_mmap() call (in mm/mmap.c), but the<br /> incomplete mm_struct can be reached through (at least) the rmap finding<br /> the vmas which have a pointer back to the mm_struct.<br /> <br /> Up to this point, there have been no issues with being able to find an<br /> mm_struct that was only partially initialised. Syzbot was able to make<br /> the incomplete mm_struct fail with recent forking changes, so it has been<br /> proven unsafe to use the mm_struct that hasn&amp;#39;t been initialised, as<br /> referenced in the link below.<br /> <br /> Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to<br /> invalid mm") fixed the uprobe access, it does not completely remove the<br /> race.<br /> <br /> This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the<br /> oom side (even though this is extremely unlikely to be selected as an oom<br /> victim in the race window), and sets MMF_UNSTABLE to avoid other potential<br /> users from using a partially initialised mm_struct.<br /> <br /> When registering vmas for uprobe, skip the vmas in an mm that is marked<br /> unstable. Modifying a vma in an unstable mm may cause issues if the mm<br /> isn&amp;#39;t fully initialised.

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: handle fastopen disconnect correctly<br /> <br /> Syzbot was able to trigger a data stream corruption:<br /> <br /> WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024<br /> RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024<br /> Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07<br /> RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293<br /> RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928<br /> R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000<br /> R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000<br /> FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074<br /> mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493<br /> release_sock+0x1aa/0x1f0 net/core/sock.c:3640<br /> inet_wait_for_connect net/ipv4/af_inet.c:609 [inline]<br /> __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703<br /> mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755<br /> mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x1a6/0x270 net/socket.c:726<br /> ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583<br /> ___sys_sendmsg net/socket.c:2637 [inline]<br /> __sys_sendmsg+0x269/0x350 net/socket.c:2669<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 /> RIP: 0033:0x7f6e86ebfe69<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69<br /> RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003<br /> RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc<br /> R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508<br /> <br /> <br /> The root cause is the bad handling of disconnect() generated internally<br /> by the MPTCP protocol in case of connect FASTOPEN errors.<br /> <br /> Address the issue increasing the socket disconnect counter even on such<br /> a case, to allow other threads waiting on the same socket lock to<br /> properly error out.