Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: use RCU protection in ip6_default_advmss()<br /> <br /> ip6_default_advmss() needs rcu protection to make<br /> sure the net structure it reads does not disappear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: use RCU protection in __ip_rt_update_pmtu()<br /> <br /> __ip_rt_update_pmtu() must use RCU protection to make<br /> sure the net structure it reads does not disappear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context<br /> <br /> The following bug report happened with a PREEMPT_RT kernel:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> get_random_u32+0x4f/0x110<br /> clocksource_verify_choose_cpus+0xab/0x1a0<br /> clocksource_verify_percpu.part.0+0x6b/0x330<br /> clocksource_watchdog_kthread+0x193/0x1a0<br /> <br /> It is due to the fact that clocksource_verify_choose_cpus() is invoked with<br /> preemption disabled. This function invokes get_random_u32() to obtain<br /> random numbers for choosing CPUs. The batched_entropy_32 local lock and/or<br /> the base_crng.lock spinlock in driver/char/random.c will be acquired during<br /> the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot<br /> be acquired in atomic context.<br /> <br /> Fix this problem by using migrate_disable() to allow smp_processor_id() to<br /> be reliably used without introducing atomic context. preempt_disable() is<br /> then called after clocksource_verify_choose_cpus() but before the<br /> clocksource measurement is being run to avoid introducing unexpected<br /> latency.