Xingwei Lee

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the `alauda init media()` function in the Linux kernel, which can cause divide errors in `alauda read data()` and `alauda write lba()` if it fails. This is due to the `uzonesize` member of `struct alauda info` remaining 0. The vulnerability can potentially lead to a denial of service. To resolve the issue, a member `media initialized` has been added to `struct alauda info`, a condition in `alauda check media()` has been changed, and an error check for the return value of `alauda init media()` has been added. **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.37 **Description** A vulnerability in the Linux kernel has been resolved, specifically a shift-out-of-bounds issue in the `dctcp update alpha()` function. The vulnerability occurs when the `dctcp shift g` module parameter is set to a value that is too large, causing a shift exponent that is too large for a 32-bit type. This issue was triggered by the syzkaller tool, which started fuzzing module parameters. The vulnerability can be exploited by setting the `dctcp shift g` parameter to a value of 100, which is too large for the 32-bit type. To fix this issue, the maximum value of `dctcp shift g` has been limited using the `param set uint minmax()` function. **Recommendations** To resolve this issue, update the Linux kernel to version 6.6.37 or later. As a temporary workaround, consider limiting the maximum value of the `dctcp shift g` module parameter to prevent shift-out-of-bounds issues.

**Name of the Vulnerable Software and Affected Versions** Linux kernel version 6.9.0-rc7 **Description** The issue arises from the FUSE NOTIFY RESEND notify sent by the write() syscall in a reproducer program. It occurs in three steps: (1) `fuse dev read()` is called to read the INIT request, which succeeds and sets the `FR SENT` bit on the request. (2) `fuse dev write()` sends a USE NOTIFY RESEND notify, causing all processing requests to be resent, and the INIT request is moved back to the pending list. (3) `fuse dev read()` is called again with an invalid output address, attempting to copy the INIT request to this address, which fails due to the invalid address and triggers a warning in `fuse request end()`. The warning is reported by lee bruce and is associated with the Linux kernel version 6.9.0-rc7. **Recommendations** To resolve the issue, clear the `FR SENT` bit when re-adding requests into the pending list. As a temporary workaround, consider restricting the use of `fuse dev read()` and `fuse dev write()` functions until a patch is available. Avoid using the `write()` syscall with the FUSE NOTIFY RESEND notify in the reproducer program until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to a bug in the Linux kernel's USB core, specifically in the `port.c` file, where the `disable store()` function does not check if the hub that the port belongs to has been concurrently removed before dereferencing the returned value of `usb hub to struct hub()`. This can lead to a null pointer dereference. The same bug exists in the `disable show()` routine. The problem can be fixed by adding a check for `hub == NULL`. 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's mm/secretmem component, where the function `folio is secretmem()` relies on secretmem folios being LRU folios to save cycles. However, folios might reside in a folio batch without the LRU flag set or have their LRU flag temporarily cleared, making the LRU flag unreliable for this purpose. This can lead to `folio is secretmem()` not detecting secretmem folios, allowing GUP-fast to succeed in grabbing a secretmem folio and potentially crashing the kernel when trying to read or write to the folio. The fix involves removing the unreliable check. **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 lock inversion deadlock in the sockmap component of the Linux kernel. This occurs when a BPF tracing program deletes elements from a sockmap/sockhash map, and locks taken during this operation are not hardirq-safe. As a result, a deadlock due to lock inversion is possible. The locks in sockmap are hardirq-unsafe by design and should only be deleted from task or softirq context with interrupts enabled. **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's inet defrag function, which can cause a problem when reassembling skb fragments via netfilter or similar modules. The function ip local out() and other functions can pass skb->sk as a function argument, and if the skb is a fragment and reassembly happens before the function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, such as openvswitch or ct act.c, when run as part of the tx pipeline. The problem arises when the skb is refragmented again right after ip do fragment() is called, which can cause the head->sk to be copied to the new fragments and set up a destructor to sock wfree. To fix this issue, the orphaning needs to be delayed long enough to learn if the skb has to be queued or if it is completing the reasm queue. 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 deadlock in the `usb deauthorize interface()` function, which can occur when another process owns the lock and tries to remove the interface. This happens because the `interface authorized store()` function acquires a device lock on an ancestor device, calling `usb deauthorize interface()`, which locks the interface's parent USB device. The deadlock occurs when `device del()` waits for all ongoing sysfs attribute callbacks to complete, but `usb deauthorize interface()` cannot complete until the device lock is released, and the lock won't be released until the removal has finished. The `sysfs break active protection()` function can be used to prevent this kind of deadlock by telling sysfs not to wait for the attribute callback. **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 netlink component of the Linux kernel, where the validation code reads past a malformed attribute due to a missing size in the minlen array for NLA BE32. This can lead to an uninit-value bug, potentially causing a denial of service. The vulnerability is associated with the `nla validate range unsigned`, `nla validate int range`, and `validate nla` functions in lib/nlattr.c. Other attributes like BITFIELD32, SINT, and UINT are also missing from the minlen array and should be added. **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 crypto component of the Linux kernel, specifically with the algif hash function. When a zero-length message is hashed by algif hash and an error is triggered, it attempts to free an SG list that was never allocated. This can lead to a denial of service. The error occurs due to a bug in the zero-length error path, where the SG list is freed unnecessarily. **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.7.0+ #58 **Description** A vulnerability in the Linux kernel has been resolved, where a bpf program using `bpf probe read kernel()` to read from the vsyscall page invokes `copy from kernel nofault()`, which in turn calls ` get user asm()`. This triggers a page fault exception because the vsyscall page address is not readable from kernel space. The `handle page fault()` function considers the vsyscall page address as a user space address instead of a kernel space address, resulting in the fix-up setup by bpf not being applied and a `page fault oops()` being invoked due to SMAP. **Recommendations** To resolve this issue, update the Linux kernel to a version that includes the fix for this vulnerability. Specifically, for Linux kernel version 6.7.0+, ensure you are running a version later than #58. If you are using an earlier version, consider upgrading to a newer version to mitigate the risk. As a temporary workaround, consider restricting the use of `bpf probe read kernel()` to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a double-free vulnerability in the ext4 file system, specifically in the `ext4 move extents()` function. This vulnerability can cause a denial of service when the `trim` command is executed, due to a zero-division bug triggered in `mb update avg fragment size()`. The problem arises when the `moved len` variable is not updated after successfully moving some extents, leading to the freeing of overlapped extents twice in `ext4 mb release inode pa()` and `ext4 process freed data()`. This results in `bb free` being incremented twice, causing the zero-division bug when `trim` is executed. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.