Guenter Roeck

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.12.0 **Description** The issue is related to a too strict alignment check in the create cache() function, which can cause a kernel panic on certain systems, such as m68k, where the minimum alignment of unsigned long is 2 bytes. The error occurs when trying to create a slab cache, resulting in a failed allocation. The problem arises from the assumption that an arbitrary freeptr t (basically an unsigned long) is always aligned to 4 or 8 bytes, which is not safe. The fix involves relaxing the check to the actual minimum alignment of freeptr t. **Recommendations** To resolve the issue, update to a version of the Linux kernel that includes the fix for the too strict alignment check in create cache(). At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to the `damon feed loop next input()` function in the Linux kernel, which is inefficient and fragile to overflows. Specifically, the `'score goal diff bp'` calculation can overflow when `'score'` is high, and the calculation of `'compensation'` is also fragile to overflow. The final calculation of the return value for the under-achieving case is again fragile to overflow when the current score is under-achieving the target. The function has been rewritten to avoid overflows and unnecessary calculations. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue arises from the unconditional call to `fec ptp save state()`, which can cause the kernel to panic on platforms that do not support PTP, such as i.MX25 and i.MX27. This happens because `fec ptp init()` is not called on these platforms, resulting in uninitialized related members in `fep`. To resolve this, a condition has been added to prevent `fec ptp save state()` from being called if PTP is not supported. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.50 **Description** The issue is related to the `pti clone pgtable()` function, which had alignment assumptions on the start address, notably assuming it is PMD aligned. This assumption is true on x86 64 but not on i386, leading to a malfunction in the end condition and resulting in a 'short' clone. The problem occurs when the user mapping has a short copy of the entry text. To resolve this, the correct increment form for `addr` should be used to avoid alignment assumptions. **Recommendations** Update to Linux kernel version 6.6.50 or later to resolve the issue. As a temporary workaround, consider restricting the use of the `pti clone pgtable()` function until a patch is available.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to a spinlock race in kernel thread creation. Context switching retains the correct lock owner across the switch from 'prev' to 'next' tasks, relying on interrupts remaining disabled for the entire duration of the switch. However, for newly created kernel threads, the status register is set to PS S in copy thread(), which leaves the IPL at 0, and upon restoring the 'next' thread's status register in switch to() aka resume(), interrupts become enabled prematurely. This causes a spinlock recursion warning as reported by Guenter Roeck. The race has been opened in commit 533e6903bea0 ("m68k: split ret from fork(), simplify kernel thread()"). Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the Linux kernel, where the iov iter unit test causes a crash on nommu systems, such as the qemu kc705-nommu emulation. The test calls the `vmap()` function directly, which is not supported on nommu systems, resulting in a kernel panic. The `TEST IOV ITER` needs to depend on `MMU` to prevent this crash. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a memory leak in the Linux kernel's handshake component. The `handshake req destroy test1` test started failing after `sock release(sock)` was replaced with `fput(filp)` to address the memory leak. The `fput(filp)` function usually delays the final close and clean-up, which is not consequential in other cases but affects the `handshake req destroy test1` test. This test checks that `handshake req cancel()` followed by closing the file actually calls the `->hp destroy` method. The delay in `fput(filp)` causes the test to fail because it cannot guarantee that the final close is complete before checking the pointer. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to an integer overflow/underflow in hysteresis calculations in the Linux kernel's hwmon component, specifically in the lm90 module. This occurs when setting the hysteresis value to MAX LONG and the critical temperature limit is negative. The problem was addressed by using the clamp val() function to prevent overflow or underflow when setting the hysteresis temperature. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.