Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()<br /> <br /> pci_get_device() will increase the reference count for the returned<br /> pci_dev. We need to use pci_dev_put() to decrease the reference count<br /> before amd_probe() returns. There is no problem for the &amp;#39;smbus_dev ==<br /> NULL&amp;#39; branch because pci_dev_put() can also handle the NULL input<br /> parameter case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm ioctl: fix misbehavior if list_versions races with module loading<br /> <br /> __list_versions will first estimate the required space using the<br /> "dm_target_iterate(list_version_get_needed, &amp;needed)" call and then will<br /> fill the space using the "dm_target_iterate(list_version_get_info,<br /> &amp;iter_info)" call. Each of these calls locks the targets using the<br /> "down_read(&amp;_lock)" and "up_read(&amp;_lock)" calls, however between the first<br /> and second "dm_target_iterate" there is no lock held and the target<br /> modules can be loaded at this point, so the second "dm_target_iterate"<br /> call may need more space than what was the first "dm_target_iterate"<br /> returned.<br /> <br /> The code tries to handle this overflow (see the beginning of<br /> list_version_get_info), however this handling is incorrect.<br /> <br /> The code sets "param-&gt;data_size = param-&gt;data_start + needed" and<br /> "iter_info.end = (char *)vers+len" - "needed" is the size returned by the<br /> first dm_target_iterate call; "len" is the size of the buffer allocated by<br /> userspace.<br /> <br /> "len" may be greater than "needed"; in this case, the code will write up<br /> to "len" bytes into the buffer, however param-&gt;data_size is set to<br /> "needed", so it may write data past the param-&gt;data_size value. The ioctl<br /> interface copies only up to param-&gt;data_size into userspace, thus part of<br /> the result will be truncated.<br /> <br /> Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this<br /> guarantees that the second "dm_target_iterate" call will write only up to<br /> the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it<br /> overflows the "needed" space - in this case, userspace will allocate a<br /> larger buffer and retry.<br /> <br /> Note that there is also a bug in list_version_get_needed - we need to add<br /> "strlen(tt-&gt;name) + 1" to the needed size, not "strlen(tt-&gt;name)".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix optc2_configure warning on dcn314<br /> <br /> [Why]<br /> dcn314 uses optc2_configure_crc() that wraps<br /> optc1_configure_crc() + set additional registers<br /> not applicable to dcn314.<br /> It&amp;#39;s not critical but when used leads to warning like:<br /> WARNING: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c<br /> Call Trace:<br /> <br /> generic_reg_set_ex+0x6d/0xe0 [amdgpu]<br /> optc2_configure_crc+0x60/0x80 [amdgpu]<br /> dc_stream_configure_crc+0x129/0x150 [amdgpu]<br /> amdgpu_dm_crtc_configure_crc_source+0x5d/0xe0 [amdgpu]<br /> <br /> [How]<br /> Use optc1_configure_crc() directly

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 /> ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open()<br /> <br /> snd_usbmidi_output_open() has a check of the NULL port with<br /> snd_BUG_ON(). snd_BUG_ON() was used as this shouldn&amp;#39;t have happened,<br /> but in reality, the NULL port may be seen when the device gives an<br /> invalid endpoint setup at the descriptor, hence the driver skips the<br /> allocation. That is, the check itself is valid and snd_BUG_ON()<br /> should be dropped from there. Otherwise it&amp;#39;s confusing as if it were<br /> a real bug, as recently syzbot stumbled on it.

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 /> 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 /> ceph: avoid putting the realm twice when decoding snaps fails<br /> <br /> When decoding the snaps fails it maybe leaving the &amp;#39;first_realm&amp;#39;<br /> and &amp;#39;realm&amp;#39; pointing to the same snaprealm memory. And then it&amp;#39;ll<br /> put it twice and could cause random use-after-free, BUG_ON, etc<br /> issues.