Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: csum: Fix OoB access in IP checksum code for negative lengths<br /> <br /> Commit 69e3a6aa6be2 ("LoongArch: Add checksum optimization for 64-bit<br /> system") would cause an undefined shift and an out-of-bounds read.<br /> <br /> Commit 8bd795fedb84 ("arm64: csum: Fix OoB access in IP checksum code<br /> for negative lengths") fixes the same issue on ARM64.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: check vxlan_vnigroup_init() return value<br /> <br /> vxlan_init() must check vxlan_vnigroup_init() success<br /> otherwise a crash happens later, spotted by syzbot.<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167]<br /> CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:vxlan_vnigroup_uninit+0x89/0x500 drivers/net/vxlan/vxlan_vnifilter.c:912<br /> Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00<br /> RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb<br /> RDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18<br /> RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000<br /> R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000<br /> FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> vxlan_uninit+0x1ab/0x200 drivers/net/vxlan/vxlan_core.c:2942<br /> unregister_netdevice_many_notify+0x12d6/0x1f30 net/core/dev.c:11824<br /> unregister_netdevice_many net/core/dev.c:11866 [inline]<br /> unregister_netdevice_queue+0x307/0x3f0 net/core/dev.c:11736<br /> register_netdevice+0x1829/0x1eb0 net/core/dev.c:10901<br /> __vxlan_dev_create+0x7c6/0xa30 drivers/net/vxlan/vxlan_core.c:3981<br /> vxlan_newlink+0xd1/0x130 drivers/net/vxlan/vxlan_core.c:4407<br /> rtnl_newlink_create net/core/rtnetlink.c:3795 [inline]<br /> __rtnl_newlink net/core/rtnetlink.c:3906 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vrf: use RCU protection in l3mdev_l3_out()<br /> <br /> l3mdev_l3_out() can be called without RCU being held:<br /> <br /> raw_sendmsg()<br /> ip_push_pending_frames()<br /> ip_send_skb()<br /> ip_local_out()<br /> __ip_local_out()<br /> l3mdev_ip_out()<br /> <br /> Add rcu_read_lock() / rcu_read_unlock() pair to avoid<br /> a potential UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: rockchip: rkcanfd_handle_rx_fifo_overflow_int(): bail out if skb cannot be allocated<br /> <br /> Fix NULL pointer check in rkcanfd_handle_rx_fifo_overflow_int() to<br /> bail out if skb cannot be allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: ctucanfd: handle skb allocation failure<br /> <br /> If skb allocation fails, the pointer to struct can_frame is NULL. This<br /> is actually handled everywhere inside ctucan_err_interrupt() except for<br /> the only place.<br /> <br /> Add the missed NULL check.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: hub: Ignore non-compliant devices with too many configs or interfaces<br /> <br /> Robert Morris created a test program which can cause<br /> usb_hub_to_struct_hub() to dereference a NULL or inappropriate<br /> pointer:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI<br /> CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14<br /> Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110<br /> ...<br /> Call Trace:<br /> <br /> ? die_addr+0x31/0x80<br /> ? exc_general_protection+0x1b4/0x3c0<br /> ? asm_exc_general_protection+0x26/0x30<br /> ? usb_hub_adjust_deviceremovable+0x78/0x110<br /> hub_probe+0x7c7/0xab0<br /> usb_probe_interface+0x14b/0x350<br /> really_probe+0xd0/0x2d0<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> __driver_probe_device+0x6e/0x110<br /> driver_probe_device+0x1a/0x90<br /> __device_attach_driver+0x7e/0xc0<br /> bus_for_each_drv+0x7f/0xd0<br /> __device_attach+0xaa/0x1a0<br /> bus_probe_device+0x8b/0xa0<br /> device_add+0x62e/0x810<br /> usb_set_configuration+0x65d/0x990<br /> usb_generic_driver_probe+0x4b/0x70<br /> usb_probe_device+0x36/0xd0<br /> <br /> The cause of this error is that the device has two interfaces, and the<br /> hub driver binds to interface 1 instead of interface 0, which is where<br /> usb_hub_to_struct_hub() looks.<br /> <br /> We can prevent the problem from occurring by refusing to accept hub<br /> devices that violate the USB spec by having more than one<br /> configuration or interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Validate the persistent meta data subbuf array<br /> <br /> The meta data for a mapped ring buffer contains an array of indexes of all<br /> the subbuffers. The first entry is the reader page, and the rest of the<br /> entries lay out the order of the subbuffers in how the ring buffer link<br /> list is to be created.<br /> <br /> The validator currently makes sure that all the entries are within the<br /> range of 0 and nr_subbufs. But it does not check if there are any<br /> duplicates.<br /> <br /> While working on the ring buffer, I corrupted this array, where I added<br /> duplicates. The validator did not catch it and created the ring buffer<br /> link list on top of it. Luckily, the corruption was only that the reader<br /> page was also in the writer path and only presented corrupted data but did<br /> not crash the kernel. But if there were duplicates in the writer side,<br /> then it could corrupt the ring buffer link list and cause a crash.<br /> <br /> Create a bitmask array with the size of the number of subbuffers. Then<br /> clear it. When walking through the subbuf array checking to see if the<br /> entries are within the range, test if its bit is already set in the<br /> subbuf_mask. If it is, then there is duplicates and fail the validation.<br /> If not, set the corresponding bit and continue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Do not allow mmap() of persistent ring buffer<br /> <br /> When trying to mmap a trace instance buffer that is attached to<br /> reserve_mem, it would crash:<br /> <br /> BUG: unable to handle page fault for address: ffffe97bd00025c8<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 2862f3067 P4D 2862f3067 PUD 0<br /> Oops: Oops: 0000 [#1] PREEMPT_RT SMP PTI<br /> CPU: 4 UID: 0 PID: 981 Comm: mmap-rb Not tainted 6.14.0-rc2-test-00003-g7f1a5e3fbf9e-dirty #233<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:validate_page_before_insert+0x5/0xb0<br /> Code: e2 01 89 d0 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 46 08 a8 01 75 67 66 90 48 89 f0 8b 50 34 85 d2 74 76 48 89<br /> RSP: 0018:ffffb148c2f3f968 EFLAGS: 00010246<br /> RAX: ffff9fa5d3322000 RBX: ffff9fa5ccff9c08 RCX: 00000000b879ed29<br /> RDX: ffffe97bd00025c0 RSI: ffffe97bd00025c0 RDI: ffff9fa5ccff9c08<br /> RBP: ffffb148c2f3f9f0 R08: 0000000000000004 R09: 0000000000000004<br /> R10: 0000000000000000 R11: 0000000000000200 R12: 0000000000000000<br /> R13: 00007f16a18d5000 R14: ffff9fa5c48db6a8 R15: 0000000000000000<br /> FS: 00007f16a1b54740(0000) GS:ffff9fa73df00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffe97bd00025c8 CR3: 00000001048c6006 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x1f<br /> ? __die+0x2e/0x40<br /> ? page_fault_oops+0x157/0x2b0<br /> ? search_module_extables+0x53/0x80<br /> ? validate_page_before_insert+0x5/0xb0<br /> ? kernelmode_fixup_or_oops.isra.0+0x5f/0x70<br /> ? __bad_area_nosemaphore+0x16e/0x1b0<br /> ? bad_area_nosemaphore+0x16/0x20<br /> ? do_kern_addr_fault+0x77/0x90<br /> ? exc_page_fault+0x22b/0x230<br /> ? asm_exc_page_fault+0x2b/0x30<br /> ? validate_page_before_insert+0x5/0xb0<br /> ? vm_insert_pages+0x151/0x400<br /> __rb_map_vma+0x21f/0x3f0<br /> ring_buffer_map+0x21b/0x2f0<br /> tracing_buffers_mmap+0x70/0xd0<br /> __mmap_region+0x6f0/0xbd0<br /> mmap_region+0x7f/0x130<br /> do_mmap+0x475/0x610<br /> vm_mmap_pgoff+0xf2/0x1d0<br /> ksys_mmap_pgoff+0x166/0x200<br /> __x64_sys_mmap+0x37/0x50<br /> x64_sys_call+0x1670/0x1d70<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The reason was that the code that maps the ring buffer pages to user space<br /> has:<br /> <br /> page = virt_to_page((void *)cpu_buffer-&gt;subbuf_ids[s]);<br /> <br /> And uses that in:<br /> <br /> vm_insert_pages(vma, vma-&gt;vm_start, pages, &amp;nr_pages);<br /> <br /> But virt_to_page() does not work with vmap()&amp;#39;d memory which is what the<br /> persistent ring buffer has. It is rather trivial to allow this, but for<br /> now just disable mmap() of instances that have their ring buffer from the<br /> reserve_mem option.<br /> <br /> If an mmap() is performed on a persistent buffer it will return -ENODEV<br /> just like it would if the .mmap field wasn&amp;#39;t defined in the<br /> file_operations structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Reject Hyper-V&amp;#39;s SEND_IPI hypercalls if local APIC isn&amp;#39;t in-kernel<br /> <br /> Advertise support for Hyper-V&amp;#39;s SEND_IPI and SEND_IPI_EX hypercalls if and<br /> only if the local API is emulated/virtualized by KVM, and explicitly reject<br /> said hypercalls if the local APIC is emulated in userspace, i.e. don&amp;#39;t rely<br /> on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.<br /> <br /> Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if<br /> Hyper-V enlightenments are exposed to the guest without an in-kernel local<br /> APIC:<br /> <br /> dump_stack+0xbe/0xfd<br /> __kasan_report.cold+0x34/0x84<br /> kasan_report+0x3a/0x50<br /> __apic_accept_irq+0x3a/0x5c0<br /> kvm_hv_send_ipi.isra.0+0x34e/0x820<br /> kvm_hv_hypercall+0x8d9/0x9d0<br /> kvm_emulate_hypercall+0x506/0x7e0<br /> __vmx_handle_exit+0x283/0xb60<br /> vmx_handle_exit+0x1d/0xd0<br /> vcpu_enter_guest+0x16b0/0x24c0<br /> vcpu_run+0xc0/0x550<br /> kvm_arch_vcpu_ioctl_run+0x170/0x6d0<br /> kvm_vcpu_ioctl+0x413/0xb20<br /> __se_sys_ioctl+0x111/0x160<br /> do_syscal1_64+0x30/0x40<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> <br /> Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode<br /> can&amp;#39;t be modified after vCPUs are created, i.e. if one vCPU has an<br /> in-kernel local APIC, then all vCPUs have an in-kernel local APIC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table()<br /> <br /> It malicious user provides a small pptable through sysfs and then<br /> a bigger pptable, it may cause buffer overflow attack in function<br /> smu_sys_set_pp_table().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: fix panic during interface removal<br /> <br /> Reference counting is used to ensure that<br /> batadv_hardif_neigh_node and batadv_hard_iface<br /> are not freed before/during<br /> batadv_v_elp_throughput_metric_update work is<br /> finished.<br /> <br /> But there isn&amp;#39;t a guarantee that the hard if will<br /> remain associated with a soft interface up until<br /> the work is finished.<br /> <br /> This fixes a crash triggered by reboot that looks<br /> like this:<br /> <br /> Call trace:<br /> batadv_v_mesh_free+0xd0/0x4dc [batman_adv]<br /> batadv_v_elp_throughput_metric_update+0x1c/0xa4<br /> process_one_work+0x178/0x398<br /> worker_thread+0x2e8/0x4d0<br /> kthread+0xd8/0xdc<br /> ret_from_fork+0x10/0x20<br /> <br /> (the batadv_v_mesh_free call is misleading,<br /> and does not actually happen)<br /> <br /> I was able to make the issue happen more reliably<br /> by changing hardif_neigh-&gt;bat_v.metric_work work<br /> to be delayed work. This allowed me to track down<br /> and confirm the fix.<br /> <br /> [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without<br /> soft_iface]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ndisc: use RCU protection in ndisc_alloc_skb()<br /> <br /> ndisc_alloc_skb() can be called without RTNL or RCU being held.<br /> <br /> Add RCU protection to avoid possible UAF.