Vulnerabilities

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.

Cross site scripting (XSS) vulnerability in Hustoj 2025-01-31 via the TID parameter to thread.php.

EzGED3 3.5.0 contains an unauthenticated arbitrary file read vulnerability due to improper access control and insufficient input validation in a script exposed via the web interface. A remote attacker can supply a crafted path parameter to a PHP script to read arbitrary files from the filesystem. The script lacks both authentication checks and secure path handling, allowing directory traversal attacks (e.g., ../../../) to access sensitive files such as configuration files, database dumps, source code, and password reset tokens. If phpMyAdmin is exposed, extracted credentials can be used for direct administrative access. In environments without such tools, attacker-controlled file reads still allow full database extraction by targeting raw MySQL data files. The vendor states that the issue is fixed in 3.5.72.27183.

EzGED3 3.5.0 stores user passwords using an insecure hashing scheme: md5(md5(password)). This hashing method is cryptographically weak and allows attackers to perform efficient offline brute-force attacks if password hashes are disclosed. The lack of salting and use of a fast, outdated algorithm makes it feasible to recover plaintext credentials using precomputed tables or GPU-based cracking tools. The vendor states that the issue is fixed in 3.5.72.27183.