Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/xen: Fix eventfd error handling in kvm_xen_eventfd_assign()<br /> <br /> Should not call eventfd_ctx_put() in case of error.<br /> <br /> [Introduce new goto target instead. - Paolo]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: cdg: allow tcp_cdg_release() to be called multiple times<br /> <br /> Apparently, mptcp is able to call tcp_disconnect() on an already<br /> disconnected flow. This is generally fine, unless current congestion<br /> control is CDG, because it might trigger a double-free [1]<br /> <br /> Instead of fixing MPTCP, and future bugs, we can make tcp_disconnect()<br /> more resilient.<br /> <br /> [1]<br /> BUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline]<br /> BUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567<br /> <br /> CPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022<br /> Workqueue: events mptcp_worker<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:317 [inline]<br /> print_report.cold+0x2ba/0x719 mm/kasan/report.c:433<br /> kasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462<br /> ____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356<br /> kasan_slab_free include/linux/kasan.h:200 [inline]<br /> slab_free_hook mm/slub.c:1759 [inline]<br /> slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785<br /> slab_free mm/slub.c:3539 [inline]<br /> kfree+0xe2/0x580 mm/slub.c:4567<br /> tcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145<br /> __mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327<br /> mptcp_do_fastclose net/mptcp/protocol.c:2592 [inline]<br /> mptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627<br /> process_one_work+0x991/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e4/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> <br /> Allocated by task 3671:<br /> kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38<br /> kasan_set_track mm/kasan/common.c:45 [inline]<br /> set_alloc_info mm/kasan/common.c:437 [inline]<br /> ____kasan_kmalloc mm/kasan/common.c:516 [inline]<br /> ____kasan_kmalloc mm/kasan/common.c:475 [inline]<br /> __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525<br /> kmalloc_array include/linux/slab.h:640 [inline]<br /> kcalloc include/linux/slab.h:671 [inline]<br /> tcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380<br /> tcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193<br /> tcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline]<br /> tcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391<br /> do_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513<br /> tcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801<br /> mptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844<br /> __sys_setsockopt+0x2d6/0x690 net/socket.c:2252<br /> __do_sys_setsockopt net/socket.c:2263 [inline]<br /> __se_sys_setsockopt net/socket.c:2260 [inline]<br /> __x64_sys_setsockopt+0xba/0x150 net/socket.c:2260<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Freed by task 16:<br /> kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38<br /> kasan_set_track+0x21/0x30 mm/kasan/common.c:45<br /> kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370<br /> ____kasan_slab_free mm/kasan/common.c:367 [inline]<br /> ____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329<br /> kasan_slab_free include/linux/kasan.h:200 [inline]<br /> slab_free_hook mm/slub.c:1759 [inline]<br /> slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785<br /> slab_free mm/slub.c:3539 [inline]<br /> kfree+0xe2/0x580 mm/slub.c:4567<br /> tcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226<br /> tcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254<br /> tcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969<br /> inet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157<br /> tcp_done+0x23b/0x340 net/ipv4/tcp.c:4649<br /> tcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624<br /> tcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525<br /> tcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759<br /> ip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439<br /> ip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484<br /> NF_HOOK include/linux/netfilter.h:302 [inline]<br /> NF_HOOK include/linux/netfilter.h:296 [inline]<br /> ip6_input+0x9c/0xd<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macvlan: enforce a consistent minimal mtu<br /> <br /> macvlan should enforce a minimal mtu of 68, even at link creation.<br /> <br /> This patch avoids the current behavior (which could lead to crashes<br /> in ipv6 stack if the link is brought up)<br /> <br /> $ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail !<br /> $ ip link sh dev macvlan1<br /> 5: macvlan1@eno1: mtu 8 qdisc noop<br /> state DOWN mode DEFAULT group default qlen 1000<br /> link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff<br /> $ ip link set macvlan1 mtu 67<br /> Error: mtu less than device minimum.<br /> $ ip link set macvlan1 mtu 68<br /> $ ip link set macvlan1 mtu 8<br /> Error: mtu less than device minimum.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: i8042 - fix leaking of platform device on module removal<br /> <br /> Avoid resetting the module-wide i8042_platform_device pointer in<br /> i8042_probe() or i8042_remove(), so that the device can be properly<br /> destroyed by i8042_exit() on module unload.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud<br /> <br /> The page table check trigger BUG_ON() unexpectedly when collapse hugepage:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at mm/page_table_check.c:82!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> Dumping ftrace buffer:<br /> (ftrace buffer empty)<br /> Modules linked in:<br /> CPU: 6 PID: 68 Comm: khugepaged Not tainted 6.1.0-rc3+ #750<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : page_table_check_clear.isra.0+0x258/0x3f0<br /> lr : page_table_check_clear.isra.0+0x240/0x3f0<br /> [...]<br /> Call trace:<br /> page_table_check_clear.isra.0+0x258/0x3f0<br /> __page_table_check_pmd_clear+0xbc/0x108<br /> pmdp_collapse_flush+0xb0/0x160<br /> collapse_huge_page+0xa08/0x1080<br /> hpage_collapse_scan_pmd+0xf30/0x1590<br /> khugepaged_scan_mm_slot.constprop.0+0x52c/0xac8<br /> khugepaged+0x338/0x518<br /> kthread+0x278/0x2f8<br /> ret_from_fork+0x10/0x20<br /> [...]<br /> <br /> Since pmd_user_accessible_page() doesn&amp;#39;t check if a pmd is leaf, it<br /> decrease file_map_count for a non-leaf pmd comes from collapse_huge_page().<br /> and so trigger BUG_ON() unexpectedly.<br /> <br /> Fix this problem by using pmd_leaf() insteal of pmd_present() in<br /> pmd_user_accessible_page(). Moreover, use pud_leaf() for<br /> pud_user_accessible_page() too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: fix use-after-free in ntfs_attr_find()<br /> <br /> Patch series "ntfs: fix bugs about Attribute", v2.<br /> <br /> This patchset fixes three bugs relative to Attribute in record:<br /> <br /> Patch 1 adds a sanity check to ensure that, attrs_offset field in first<br /> mft record loading from disk is within bounds.<br /> <br /> Patch 2 moves the ATTR_RECORD&amp;#39;s bounds checking earlier, to avoid<br /> dereferencing ATTR_RECORD before checking this ATTR_RECORD is within<br /> bounds.<br /> <br /> Patch 3 adds an overflow checking to avoid possible forever loop in<br /> ntfs_attr_find().<br /> <br /> Without patch 1 and patch 2, the kernel triggersa KASAN use-after-free<br /> detection as reported by Syzkaller.<br /> <br /> Although one of patch 1 or patch 2 can fix this, we still need both of<br /> them. Because patch 1 fixes the root cause, and patch 2 not only fixes<br /> the direct cause, but also fixes the potential out-of-bounds bug.<br /> <br /> <br /> This patch (of 3):<br /> <br /> Syzkaller reported use-after-free read as follows:<br /> ==================================================================<br /> BUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597<br /> Read of size 2 at addr ffff88807e352009 by task syz-executor153/3607<br /> <br /> [...]<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:317 [inline]<br /> print_report.cold+0x2ba/0x719 mm/kasan/report.c:433<br /> kasan_report+0xb1/0x1e0 mm/kasan/report.c:495<br /> ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597<br /> ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193<br /> ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845<br /> ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854<br /> mount_bdev+0x34d/0x410 fs/super.c:1400<br /> legacy_get_tree+0x105/0x220 fs/fs_context.c:610<br /> vfs_get_tree+0x89/0x2f0 fs/super.c:1530<br /> do_new_mount fs/namespace.c:3040 [inline]<br /> path_mount+0x1326/0x1e20 fs/namespace.c:3370<br /> do_mount fs/namespace.c:3383 [inline]<br /> __do_sys_mount fs/namespace.c:3591 [inline]<br /> __se_sys_mount fs/namespace.c:3568 [inline]<br /> __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> <br /> <br /> The buggy address belongs to the physical page:<br /> page:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350<br /> head:ffffea0001f8d400 order:3 compound_mapcount:0 compound_pincount:0<br /> flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)<br /> raw: 00fff00000010200 0000000000000000 dead000000000122 ffff888011842140<br /> raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> Memory state around the buggy address:<br /> ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> &gt;ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ==================================================================<br /> <br /> Kernel will loads $MFT/$DATA&amp;#39;s first mft record in<br /> ntfs_read_inode_mount().<br /> <br /> Yet the problem is that after loading, kernel doesn&amp;#39;t check whether<br /> attrs_offset field is a valid value.<br /> <br /> To be more specific, if attrs_offset field is larger than bytes_allocated<br /> field, then it may trigger the out-of-bounds read bug(reported as<br /> use-after-free bug) in ntfs_attr_find(), when kernel tries to access the<br /> corresponding mft record&amp;#39;s attribute.<br /> <br /> This patch solves it by adding the sanity check between attrs_offset field<br /> and bytes_allocated field, after loading the first mft record.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Prevent bpf program recursion for raw tracepoint probes<br /> <br /> We got report from sysbot [1] about warnings that were caused by<br /> bpf program attached to contention_begin raw tracepoint triggering<br /> the same tracepoint by using bpf_trace_printk helper that takes<br /> trace_printk_lock lock.<br /> <br /> Call Trace:<br /> <br /> ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90<br /> bpf_trace_printk+0x2b/0xe0<br /> bpf_prog_a9aec6167c091eef_prog+0x1f/0x24<br /> bpf_trace_run2+0x26/0x90<br /> native_queued_spin_lock_slowpath+0x1c6/0x2b0<br /> _raw_spin_lock_irqsave+0x44/0x50<br /> bpf_trace_printk+0x3f/0xe0<br /> bpf_prog_a9aec6167c091eef_prog+0x1f/0x24<br /> bpf_trace_run2+0x26/0x90<br /> native_queued_spin_lock_slowpath+0x1c6/0x2b0<br /> _raw_spin_lock_irqsave+0x44/0x50<br /> bpf_trace_printk+0x3f/0xe0<br /> bpf_prog_a9aec6167c091eef_prog+0x1f/0x24<br /> bpf_trace_run2+0x26/0x90<br /> native_queued_spin_lock_slowpath+0x1c6/0x2b0<br /> _raw_spin_lock_irqsave+0x44/0x50<br /> bpf_trace_printk+0x3f/0xe0<br /> bpf_prog_a9aec6167c091eef_prog+0x1f/0x24<br /> bpf_trace_run2+0x26/0x90<br /> native_queued_spin_lock_slowpath+0x1c6/0x2b0<br /> _raw_spin_lock_irqsave+0x44/0x50<br /> __unfreeze_partials+0x5b/0x160<br /> ...<br /> <br /> The can be reproduced by attaching bpf program as raw tracepoint on<br /> contention_begin tracepoint. The bpf prog calls bpf_trace_printk<br /> helper. Then by running perf bench the spin lock code is forced to<br /> take slow path and call contention_begin tracepoint.<br /> <br /> Fixing this by skipping execution of the bpf program if it&amp;#39;s<br /> already running, Using bpf prog &amp;#39;active&amp;#39; field, which is being<br /> currently used by trampoline programs for the same reason.<br /> <br /> Moving bpf_prog_inc_misses_counter to syscall.c because<br /> trampoline.c is compiled in just for CONFIG_BPF_JIT option.<br /> <br /> [1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/9p: use a dedicated spinlock for trans_fd<br /> <br /> Shamelessly copying the explanation from Tetsuo Handa&amp;#39;s suggested<br /> patch[1] (slightly reworded):<br /> syzbot is reporting inconsistent lock state in p9_req_put()[2],<br /> for p9_tag_remove() from p9_req_put() from IRQ context is using<br /> spin_lock_irqsave() on "struct p9_client"-&gt;lock but trans_fd<br /> (not from IRQ context) is using spin_lock().<br /> <br /> Since the locks actually protect different things in client.c and in<br /> trans_fd.c, just replace trans_fd.c&amp;#39;s lock by a new one specific to the<br /> transport (client.c&amp;#39;s protect the idr for fid/tag allocations,<br /> while trans_fd.c&amp;#39;s protects its own req list and request status field<br /> that acts as the transport&amp;#39;s state machine)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: Bounds-check struct nlmsgerr creation<br /> <br /> In preparation for FORTIFY_SOURCE doing bounds-check on memcpy(),<br /> switch from __nlmsg_put to nlmsg_put(), and explain the bounds check<br /> for dealing with the memcpy() across a composite flexible array struct.<br /> Avoids this future run-time warning:<br /> <br /> memcpy: detected field-spanning write (size 32) of single field "&amp;errmsg-&gt;msg" at net/netlink/af_netlink.c:2447 (size 16)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p/trans_fd: always use O_NONBLOCK read/write<br /> <br /> syzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop()<br /> from p9_conn_destroy() from p9_fd_close() is failing to interrupt already<br /> started kernel_read() from p9_fd_read() from p9_read_work() and/or<br /> kernel_write() from p9_fd_write() from p9_write_work() requests.<br /> <br /> Since p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not<br /> need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open()<br /> does not set O_NONBLOCK flag, but pipe blocks unless signal is pending,<br /> p9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when<br /> the file descriptor refers to a pipe. In other words, pipe file descriptor<br /> needs to be handled as if socket file descriptor.<br /> <br /> We somehow need to interrupt kernel_read()/kernel_write() on pipes.<br /> <br /> A minimal change, which this patch is doing, is to set O_NONBLOCK flag<br /> from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing<br /> of regular files. But this approach changes O_NONBLOCK flag on userspace-<br /> supplied file descriptors (which might break userspace programs), and<br /> O_NONBLOCK flag could be changed by userspace. It would be possible to set<br /> O_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still<br /> remains small race window for clearing O_NONBLOCK flag.<br /> <br /> If we don&amp;#39;t want to manipulate O_NONBLOCK flag, we might be able to<br /> surround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING)<br /> and recalc_sigpending(). Since p9_read_work()/p9_write_work() works are<br /> processed by kernel threads which process global system_wq workqueue,<br /> signals could not be delivered from remote threads when p9_mux_poll_stop()<br /> from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling<br /> set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be<br /> needed if we count on signals for making kernel_read()/kernel_write()<br /> non-blocking.<br /> <br /> [Dominique: add comment at Christian&amp;#39;s suggestion]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p: trans_fd/p9_conn_cancel: drop client lock earlier<br /> <br /> syzbot reported a double-lock here and we no longer need this<br /> lock after requests have been moved off to local list:<br /> just drop the lock earlier.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Check sb_bsize_shift after reading superblock<br /> <br /> Fuzzers like to scribble over sb_bsize_shift but in reality it&amp;#39;s very<br /> unlikely that this field would be corrupted on its own. Nevertheless it<br /> should be checked to avoid the possibility of messy mount errors due to<br /> bad calculations. It&amp;#39;s always a fixed value based on the block size so<br /> we can just check that it&amp;#39;s the expected value.<br /> <br /> Tested with:<br /> <br /> mkfs.gfs2 -O -p lock_nolock /dev/vdb<br /> for i in 0 -1 64 65 32 33; do<br /> gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb<br /> mount /dev/vdb /mnt/test &amp;&amp; umount /mnt/test<br /> done<br /> <br /> Before this patch we get a withdraw after<br /> <br /> [ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block<br /> [ 76.413681] bh = 19 (type: exp=5, found=4)<br /> [ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492<br /> <br /> and with UBSAN configured we also get complaints like<br /> <br /> [ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19<br /> [ 76.373815] shift exponent 4294967287 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;<br /> <br /> After the patch, these complaints don&amp;#39;t appear, mount fails immediately<br /> and we get an explanation in dmesg.