Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Prevent VMA split of buffer mappings<br /> <br /> The perf mmap code is careful about mmap()&amp;#39;ing the user page with the<br /> ringbuffer and additionally the auxiliary buffer, when the event supports<br /> it. Once the first mapping is established, subsequent mapping have to use<br /> the same offset and the same size in both cases. The reference counting for<br /> the ringbuffer and the auxiliary buffer depends on this being correct.<br /> <br /> Though perf does not prevent that a related mapping is split via mmap(2),<br /> munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,<br /> which take reference counts, but then the subsequent perf_mmap_close()<br /> calls are not longer fulfilling the offset and size checks. This leads to<br /> reference count leaks.<br /> <br /> As perf already has the requirement for subsequent mappings to match the<br /> initial mapping, the obvious consequence is that VMA splits, caused by<br /> resizing of a mapping or partial unmapping, have to be prevented.<br /> <br /> Implement the vm_operations_struct::may_split() callback and return<br /> unconditionally -EINVAL.<br /> <br /> That ensures that the mapping offsets and sizes cannot be changed after the<br /> fact. Remapping to a different fixed address with the same size is still<br /> possible as it takes the references for the new mapping and drops those of<br /> the old mapping.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: Initialize frame-based format color matching descriptor<br /> <br /> Fix NULL pointer crash in uvcg_framebased_make due to uninitialized color<br /> matching descriptor for frame-based format which was added in<br /> commit f5e7bdd34aca ("usb: gadget: uvc: Allow creating new color matching<br /> descriptors") that added handling for uncompressed and mjpeg format.<br /> <br /> Crash is seen when userspace configuration (via configfs) does not<br /> explicitly define the color matching descriptor. If color_matching is not<br /> found, config_group_find_item() returns NULL. The code then jumps to<br /> out_put_cm, where it calls config_item_put(color_matching);. If<br /> color_matching is NULL, this will dereference a null pointer, leading to a<br /> crash.<br /> <br /> [ 2.746440] Unable to handle kernel NULL pointer dereference at virtual address 000000000000008c<br /> [ 2.756273] Mem abort info:<br /> [ 2.760080] ESR = 0x0000000096000005<br /> [ 2.764872] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 2.771068] SET = 0, FnV = 0<br /> [ 2.771069] EA = 0, S1PTW = 0<br /> [ 2.771070] FSC = 0x05: level 1 translation fault<br /> [ 2.771071] Data abort info:<br /> [ 2.771072] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 2.771073] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 2.771074] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 2.771075] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000a3e59000<br /> [ 2.771077] [000000000000008c] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 2.771081] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> [ 2.771084] Dumping ftrace buffer:<br /> [ 2.771085] (ftrace buffer empty)<br /> [ 2.771138] CPU: 7 PID: 486 Comm: ln Tainted: G W E 6.6.58-android15<br /> [ 2.771139] Hardware name: Qualcomm Technologies, Inc. SunP QRD HDK (DT)<br /> [ 2.771140] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 2.771141] pc : __uvcg_fill_strm+0x198/0x2cc<br /> [ 2.771145] lr : __uvcg_iter_strm_cls+0xc8/0x17c<br /> [ 2.771146] sp : ffffffc08140bbb0<br /> [ 2.771146] x29: ffffffc08140bbb0 x28: ffffff803bc81380 x27: ffffff8023bbd250<br /> [ 2.771147] x26: ffffff8023bbd250 x25: ffffff803c361348 x24: ffffff803d8e6768<br /> [ 2.771148] x23: 0000000000000004 x22: 0000000000000003 x21: ffffffc08140bc48<br /> [ 2.771149] x20: 0000000000000000 x19: ffffffc08140bc48 x18: ffffffe9f8cf4a00<br /> [ 2.771150] x17: 000000001bf64ec3 x16: 000000001bf64ec3 x15: ffffff8023bbd250<br /> [ 2.771151] x14: 000000000000000f x13: 004c4b40000f4240 x12: 000a2c2a00051615<br /> [ 2.771152] x11: 000000000000004f x10: ffffffe9f76b40ec x9 : ffffffe9f7e389d0<br /> [ 2.771153] x8 : ffffff803d0d31ce x7 : 000f4240000a2c2a x6 : 0005161500028b0a<br /> [ 2.771154] x5 : ffffff803d0d31ce x4 : 0000000000000003 x3 : 0000000000000000<br /> [ 2.771155] x2 : ffffffc08140bc50 x1 : ffffffc08140bc48 x0 : 0000000000000000<br /> [ 2.771156] Call trace:<br /> [ 2.771157] __uvcg_fill_strm+0x198/0x2cc<br /> [ 2.771157] __uvcg_iter_strm_cls+0xc8/0x17c<br /> [ 2.771158] uvcg_streaming_class_allow_link+0x240/0x290<br /> [ 2.771159] configfs_symlink+0x1f8/0x630<br /> [ 2.771161] vfs_symlink+0x114/0x1a0<br /> [ 2.771163] do_symlinkat+0x94/0x28c<br /> [ 2.771164] __arm64_sys_symlinkat+0x54/0x70<br /> [ 2.771164] invoke_syscall+0x58/0x114<br /> [ 2.771166] el0_svc_common+0x80/0xe0<br /> [ 2.771168] do_el0_svc+0x1c/0x28<br /> [ 2.771169] el0_svc+0x3c/0x70<br /> [ 2.771172] el0t_64_sync_handler+0x68/0xbc<br /> [ 2.771173] el0t_64_sync+0x1a8/0x1ac<br /> <br /> Initialize color matching descriptor for frame-based format to prevent<br /> NULL pointer crash by mirroring the handling done for uncompressed and<br /> mjpeg formats.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/intel/pmt: fix a crashlog NULL pointer access<br /> <br /> Usage of the intel_pmt_read() for binary sysfs, requires a pcidev. The<br /> current use of the endpoint value is only valid for telemetry endpoint<br /> usage.<br /> <br /> Without the ep, the crashlog usage causes the following NULL pointer<br /> exception:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> RIP: 0010:intel_pmt_read+0x3b/0x70 [pmt_class]<br /> Code:<br /> Call Trace:<br /> <br /> ? sysfs_kf_bin_read+0xc0/0xe0<br /> kernfs_fop_read_iter+0xac/0x1a0<br /> vfs_read+0x26d/0x350<br /> ksys_read+0x6b/0xe0<br /> __x64_sys_read+0x1d/0x30<br /> x64_sys_call+0x1bc8/0x1d70<br /> do_syscall_64+0x6d/0x110<br /> <br /> Augment struct intel_pmt_entry with a pointer to the pcidev to avoid<br /> the NULL pointer exception.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Handle buffer mapping fail correctly in perf_mmap()<br /> <br /> After successful allocation of a buffer or a successful attachment to an<br /> existing buffer perf_mmap() tries to map the buffer read only into the page<br /> table. If that fails, the already set up page table entries are zapped, but<br /> the other perf specific side effects of that failure are not handled. The<br /> calling code just cleans up the VMA and does not invoke perf_mmap_close().<br /> <br /> This leaks reference counts, corrupts user-&gt;vm accounting and also results<br /> in an unbalanced invocation of event::event_mapped().<br /> <br /> Cure this by moving the event::event_mapped() invocation before the<br /> map_range() call so that on map_range() failure perf_mmap_close() can be<br /> invoked without causing an unbalanced event::event_unmapped() call.<br /> <br /> perf_mmap_close() undoes the reference counts and eventually frees buffers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/sev: Evict cache lines during SNP memory validation<br /> <br /> An SNP cache coherency vulnerability requires a cache line eviction<br /> mitigation when validating memory after a page state change to private.<br /> The specific mitigation is to touch the first and last byte of each 4K<br /> page that is being validated. There is no need to perform the mitigation<br /> when performing a page state change to shared and rescinding validation.<br /> <br /> CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit<br /> that, when set, indicates that the software mitigation for this<br /> vulnerability is not needed.<br /> <br /> Implement the mitigation and invoke it when validating memory (making it<br /> private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP<br /> guest is vulnerable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget : fix use-after-free in composite_dev_cleanup()<br /> <br /> 1. In func configfs_composite_bind() -&gt; composite_os_desc_req_prepare():<br /> if kmalloc fails, the pointer cdev-&gt;os_desc_req will be freed but not<br /> set to NULL. Then it will return a failure to the upper-level function.<br /> 2. in func configfs_composite_bind() -&gt; composite_dev_cleanup():<br /> it will checks whether cdev-&gt;os_desc_req is NULL. If it is not NULL, it<br /> will attempt to use it.This will lead to a use-after-free issue.<br /> <br /> BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0<br /> Read of size 8 at addr 0000004827837a00 by task init/1<br /> <br /> CPU: 10 PID: 1 Comm: init Tainted: G O 5.10.97-oh #1<br /> kasan_report+0x188/0x1cc<br /> __asan_load8+0xb4/0xbc<br /> composite_dev_cleanup+0xf4/0x2c0<br /> configfs_composite_bind+0x210/0x7ac<br /> udc_bind_to_driver+0xb4/0x1ec<br /> usb_gadget_probe_driver+0xec/0x21c<br /> gadget_dev_desc_UDC_store+0x264/0x27c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix a UAF when vma-&gt;mm is freed after vma-&gt;vm_refcnt got dropped<br /> <br /> By inducing delays in the right places, Jann Horn created a reproducer for<br /> a hard to hit UAF issue that became possible after VMAs were allowed to be<br /> recycled by adding SLAB_TYPESAFE_BY_RCU to their cache.<br /> <br /> Race description is borrowed from Jann&amp;#39;s discovery report:<br /> lock_vma_under_rcu() looks up a VMA locklessly with mas_walk() under<br /> rcu_read_lock(). At that point, the VMA may be concurrently freed, and it<br /> can be recycled by another process. vma_start_read() then increments the<br /> vma-&gt;vm_refcnt (if it is in an acceptable range), and if this succeeds,<br /> vma_start_read() can return a recycled VMA.<br /> <br /> In this scenario where the VMA has been recycled, lock_vma_under_rcu()<br /> will then detect the mismatching -&gt;vm_mm pointer and drop the VMA through<br /> vma_end_read(), which calls vma_refcount_put(). vma_refcount_put() drops<br /> the refcount and then calls rcuwait_wake_up() using a copy of vma-&gt;vm_mm. <br /> This is wrong: It implicitly assumes that the caller is keeping the VMA&amp;#39;s<br /> mm alive, but in this scenario the caller has no relation to the VMA&amp;#39;s mm,<br /> so the rcuwait_wake_up() can cause UAF.<br /> <br /> The diagram depicting the race:<br /> T1 T2 T3<br /> == == ==<br /> lock_vma_under_rcu<br /> mas_walk<br /> <br /> mmap<br /> <br /> vma_start_read<br /> __refcount_inc_not_zero_limited_acquire<br /> munmap<br /> __vma_enter_locked<br /> refcount_add_not_zero<br /> vma_end_read<br /> vma_refcount_put<br /> __refcount_dec_and_test<br /> rcuwait_wait_event<br /> <br /> rcuwait_wake_up [UAF]<br /> <br /> Note that rcuwait_wait_event() in T3 does not block because refcount was<br /> already dropped by T1. At this point T3 can exit and free the mm causing<br /> UAF in T1.<br /> <br /> To avoid this we move vma-&gt;vm_mm verification into vma_start_read() and<br /> grab vma-&gt;vm_mm to stabilize it before vma_refcount_put() operation.<br /> <br /> [surenb@google.com: v3]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: apple: validate feature-report field count to prevent NULL pointer dereference<br /> <br /> A malicious HID device with quirk APPLE_MAGIC_BACKLIGHT can trigger a NULL<br /> pointer dereference whilst the power feature-report is toggled and sent to<br /> the device in apple_magic_backlight_report_set(). The power feature-report<br /> is expected to have two data fields, but if the descriptor declares one<br /> field then accessing field[1] and dereferencing it in<br /> apple_magic_backlight_report_set() becomes invalid<br /> since field[1] will be NULL.<br /> <br /> An example of a minimal descriptor which can cause the crash is something<br /> like the following where the report with ID 3 (power report) only<br /> references a single 1-byte field. When hid core parses the descriptor it<br /> will encounter the final feature tag, allocate a hid_report (all members<br /> of field[] will be zeroed out), create field structure and populate it,<br /> increasing the maxfield to 1. The subsequent field[1] access and<br /> dereference causes the crash.<br /> <br /> Usage Page (Vendor Defined 0xFF00)<br /> Usage (0x0F)<br /> Collection (Application)<br /> Report ID (1)<br /> Usage (0x01)<br /> Logical Minimum (0)<br /> Logical Maximum (255)<br /> Report Size (8)<br /> Report Count (1)<br /> Feature (Data,Var,Abs)<br /> <br /> Usage (0x02)<br /> Logical Maximum (32767)<br /> Report Size (16)<br /> Report Count (1)<br /> Feature (Data,Var,Abs)<br /> <br /> Report ID (3)<br /> Usage (0x03)<br /> Logical Minimum (0)<br /> Logical Maximum (1)<br /> Report Size (8)<br /> Report Count (1)<br /> Feature (Data,Var,Abs)<br /> End Collection<br /> <br /> Here we see the KASAN splat when the kernel dereferences the<br /> NULL pointer and crashes:<br /> <br /> [ 15.164723] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI<br /> [ 15.165691] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]<br /> [ 15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0 #31 PREEMPT(voluntary)<br /> [ 15.165691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> [ 15.165691] RIP: 0010:apple_magic_backlight_report_set+0xbf/0x210<br /> [ 15.165691] Call Trace:<br /> [ 15.165691] <br /> [ 15.165691] apple_probe+0x571/0xa20<br /> [ 15.165691] hid_device_probe+0x2e2/0x6f0<br /> [ 15.165691] really_probe+0x1ca/0x5c0<br /> [ 15.165691] __driver_probe_device+0x24f/0x310<br /> [ 15.165691] driver_probe_device+0x4a/0xd0<br /> [ 15.165691] __device_attach_driver+0x169/0x220<br /> [ 15.165691] bus_for_each_drv+0x118/0x1b0<br /> [ 15.165691] __device_attach+0x1d5/0x380<br /> [ 15.165691] device_initial_probe+0x12/0x20<br /> [ 15.165691] bus_probe_device+0x13d/0x180<br /> [ 15.165691] device_add+0xd87/0x1510<br /> [...]<br /> <br /> To fix this issue we should validate the number of fields that the<br /> backlight and power reports have and if they do not have the required<br /> number of fields then bail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: Harden s32ton() against conversion to 0 bits<br /> <br /> Testing by the syzbot fuzzer showed that the HID core gets a<br /> shift-out-of-bounds exception when it tries to convert a 32-bit<br /> quantity to a 0-bit quantity. Ideally this should never occur, but<br /> there are buggy devices and some might have a report field with size<br /> set to zero; we shouldn&amp;#39;t reject the report or the device just because<br /> of that.<br /> <br /> Instead, harden the s32ton() routine so that it returns a reasonable<br /> result instead of crashing when it is called with the number of bits<br /> set to 0 -- the same as what snto32() does.

Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. Reason: This candidate was issued in error. Notes: All references and descriptions in this candidate have been removed to prevent accidental usage.

A security vulnerability has been detected in Scada-LTS 2.7.8.1. This issue affects some unknown processing of the file view_edit.shtm of the component SVG File Handler. Such manipulation of the argument backgroundImageMP leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed publicly and may be used.

A flaw has been found in Linksys E5600 1.1.0.26. The affected element is the function verify_gemtek_header of the file checkFw.sh of the component Firmware Handler. Executing manipulation can lead to risky cryptographic algorithm. The attack may be launched remotely. The attack requires a high level of complexity. The exploitability is described as difficult. The vendor was contacted early about this disclosure but did not respond in any way.