Yue Sun

A potential NULL pointer dereference issue was found in the Linux kernel, specifically in the etas es58x driver. The driver incorrectly assumed that `es58x dev->udev->serial` could never be NULL. However, an attacker could potentially spoof the device identity by providing a NULL USB serial number, triggering a NULL pointer dereference. The issue was resolved by adding a check on `es58x dev->udev->serial` before accessing it.

A use-after-free issue was found in the Linux kernel, specifically in the corsair-void module, due to a missing call to cancel delayed work sync(). This caused a problem when the corsair void remove() function was called.

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.

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.

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.

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.

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.

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.

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.

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.

The issue was addressed with improved checks. Processing maliciously crafted web content may lead to arbitrary code execution.

A memory consumption issue was addressed with improved memory handling. Processing maliciously crafted web content may lead to arbitrary code execution. The issue is related to a buffer overflow vulnerability in WebKitGTK and WPE WebKit modules, which can allow a remote attacker to access confidential data, compromise data integrity, and cause a denial of service.