Sashiko

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A use-after-free and resource leak issue exists in the `spi: mpc52xx` component. The problem occurs when controller registration fails, as interrupts are not properly disabled and freed. **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 7.0.11-1.1 **Description** An issue exists in the RDMA/mana component where the `rx hash key len` variable, which originates from a uAPI structure, is passed to the `memcpy()` function without proper validation. This lack of bounds checking allows userspace applications to cause a memory overflow, potentially leading to the corruption of kernel memory. **Recommendations** Update to version 7.0.11-1.1.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) openSUSE Tumbleweed versions prior to kernel-devel-7.0.11-1.1 **Description** A resource leak occurs in the RDMA/mlx4 component of the Linux kernel. The issue exists within the `mlx4 ib create srq()` function, where the `mlx4 srq alloc()` function is not properly undone during error unwind, leading to a failure to call `mlx4 srq free()`. **Recommendations** Update to a version where the `mlx4 srq free()` call has been added to the error unwind path in `mlx4 ib create srq()`. Update to kernel-devel-7.0.11-1.1 or a newer version.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) openSUSE Tumbleweed versions prior to kernel-devel-7.0.11-1.1 **Description** An out-of-bounds read exists in the `spi nor params show()` function within the spi-nor debugfs component. The issue occurs because the `snor f names` array is passed to the `spi nor print flags()` function using `sizeof()`, which returns the total byte size of the pointer array rather than the number of elements. On 64-bit systems, this results in a length eight times larger than intended. If a flag bit is set that exceeds the actual element count but falls within the inflated byte-size count, the `names len` argument fails to properly bounds-check the `names` array access, leading to an out-of-bounds read. **Recommendations** Update to a version where `ARRAY SIZE()` is used instead of `sizeof()` to pass the actual number of string pointers in the array. Update to kernel-devel-7.0.11-1.1 or a newer version.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 7.0.11-1.1 **Description** A memory corruption issue exists in the RDMA hns component. The function `hns roce qp remove()` is called without the required locks during the error unwind process within the `hns roce create qp common()` function. **Recommendations** Update to version 7.0.11-1.1.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A NULL pointer dereference occurs in the RDMA/ocrdma component within the `ocrdma copy pd uresp()` function. The issue arises because `pd->uctx` is not initialized until late in the function execution, causing error flow references to be NULL and resulting in a system 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) openSUSE Tumbleweed versions prior to kernel-devel-7.0.11-1.1 **Description** An error unwind issue exists in the RDMA mana component. Specifically, the `mana ib create qp rss()` function fails to properly handle error unwinding, which leads to a leak of `mana ib cfg vport steering()`. This resource is typically cleaned up during the normal destroy path but is not handled correctly during the error path. **Recommendations** Update to a version of the Linux kernel where the `mana ib create qp rss()` error unwind is fixed. Update to kernel-devel-7.0.11-1.1 or a newer version for openSUSE Tumbleweed.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A race condition exists between the `damos walk()` and `kdamond fn()` functions. When the `kdamond fn()` main loop finishes, it cancels remaining `damos walk()` requests and unsets `damon ctx->kdamond`. Because request registration and the unsetting of `damon ctx->kdamond` are protected by different mutexes, `damos walk()` may register a new request and perceive the context as still running just before `damon ctx->kdamond` is unset. This leads to a situation where the caller thread waits indefinitely for a request that will never be handled, resulting in a deadlock. **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** A race condition exists between the `damon call()` and `damos walk()` functions and the `kdamond fn()` termination process. Because the registration of requests in `damon call()` and the unsetting of `damon ctx->kdamond` are protected by different mutexes, a caller may register a new request and begin waiting for it just as the `kdamond` thread is terminating. Since the terminating thread no longer handles new requests, this leads to infinite waiting and deadlocks. Additionally, if a request in repeat mode includes `dealloc on cancel`, memory leaks may occur. **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** An issue exists in the ext4 filesystem where pending discard work is not properly handled during remounting. If a filesystem is initially mounted with the discard option and files are deleted, the `s discard list` is populated and `s discard work` is queued. If the filesystem is subsequently remounted with the nodiscard option, the `EXT4 MOUNT DISCARD` flag is cleared, but the pending `s discard work` is neither cancelled nor flushed. This can lead to a bug when the filesystem is unmounted before the queued work drains automatically. The flaw involves the `ext4 mb release()` function. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.