Ignat Korchagin

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.74 **Description** The issue is related to the Bluetooth L2CAP protocol in the Linux kernel. Specifically, in the `l2cap sock create()` function, a dangling pointer to the `sk` object may be left attached to the `sock` object when an error occurs during `bt sock alloc()`. This can lead to a use-after-free condition in other parts of the code. The `bt sock alloc()` function allocates the `sk` object and attaches it to the provided `sock` object. However, when an error occurs, `l2cap sock alloc()` frees the `sk` object, but the dangling pointer remains attached to the `sock` object. **Recommendations** For Linux kernel versions prior to 6.6.74, update to version 6.6.74 or later to resolve the issue. As a temporary workaround, consider disabling Bluetooth functionality until a patch is available. Restrict access to the `l2cap sock create()` function to minimize the risk of exploitation. Avoid using the `bt sock alloc()` function in error-prone code paths until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.74 **Description** A vulnerability in the Linux kernel's Bluetooth RFCOMM implementation could lead to a use-after-free issue. This occurs because `bt sock alloc()` attaches an allocated `sk` object to the provided `sock` object, and if `rfcomm dlc alloc()` fails, the `sk` object is released, but a dangling pointer remains in the `sock` object. The issue is resolved by swapping the calls to `bt sock alloc()` and `rfcomm dlc alloc()`. **Recommendations** For Linux kernel versions prior to 6.6.74, update to version 6.6.74 or later to resolve the issue. As a temporary workaround, consider restricting the use of Bluetooth RFCOMM functionality until the update is applied.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.74 **Description** A vulnerability in the Linux kernel has been resolved, specifically in the af packet module. The issue occurs after the sock init data() function is called in packet create(), where the allocated sk object is attached to the provided sock object. If an error occurs, packet create() frees the sk object, leaving a dangling pointer in the sock object. This can cause use-after-free errors if other code attempts to use the pointer. **Recommendations** For Linux kernel versions prior to 6.6.74, update to version 6.6.74 or later to resolve the issue. As a temporary workaround, consider restricting access to the af packet module until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.74 **Description** A vulnerability in the Linux kernel has been resolved, where the `inet6 create()` function did not properly clear a dangling `sk` pointer. The `sock init data()` function attaches the allocated `sk` pointer to the provided `sock` object. If `inet6 create()` fails later, the `sk` object is released, but the `sock` object retains the dangling `sk` pointer, which may cause a use-after-free error later. **Recommendations** For Linux kernel versions prior to 6.6.74, update to version 6.6.74 or later to resolve the issue. As a temporary workaround, consider implementing custom error handling to clear the `sk` pointer in case of an error in `inet6 create()`. Restrict access to the `inet6 create()` function to minimize the risk of exploitation until the update is applied.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.74 **Description** A vulnerability in the Linux kernel has been resolved, where the `inet create()` function could leave a dangling `sk` pointer. The `sock init data()` function attaches the allocated `sk` object to the provided `sock` object. If `inet create()` fails later, the `sk` object is freed, but the `sock` object retains the dangling pointer, which may create a use-after-free issue later. The fix involves clearing the `sk` pointer in the `sock` object on error. **Recommendations** For Linux kernel versions prior to 6.6.74, update to version 6.6.74 or later to resolve the issue. As a temporary workaround, consider implementing custom error handling to clear the `sk` pointer in the `sock` object when `inet create()` fails.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.74 **Description** A vulnerability in the Linux kernel has been resolved, specifically in the net: ieee802154 module. The issue arises when the `ieee802154 create()` function fails, causing a dangling pointer to remain in the provided sock object after the allocated sk object is freed. This may allow use-after-free. The `sock init data()` function attaches the allocated sk object to the provided sock object. **Recommendations** For Linux kernel versions prior to 6.6.74, update to version 6.6.74 or later to resolve the issue. As a temporary workaround, consider implementing error handling to clear the sk pointer in the sock object on error, similar to the fix applied in the resolved version.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.6.74 **Description** A vulnerability in the Linux kernel has been resolved, specifically in the `can create()` function. On error, `can create()` frees the allocated `sk` object, but `sock init data()` has already attached it to the provided `sock` object. This leaves a dangling `sk` pointer in the `sock` object and may cause use-after-free later. **Recommendations** For Linux kernel versions prior to 6.6.74, update to version 6.6.74 or later to resolve the issue. As a temporary workaround, consider restricting access to the `can create()` function until a patch is available. Avoid using the `sk` object in the affected `can create()` function until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: A vulnerability in the Linux kernel has been resolved, related to the network code where the `sk` pointer was not being cleared properly when `pf->create` fails. This issue was noticed after a previous commit did not fully address the problem, as some `pf->create` implementations do not use `sk common release` in their error paths. For example, using `arping` with an `AF PACKET` socket can demonstrate the issue if `packet create` fails. The problem is that future protocols may make the same mistake, so it is easier to explicitly clear the `sk` pointer upon return from `pf->create` in ` sock create`. 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.10.0-rc2+ **Description** The vulnerability is related to a use-after-free issue in the Linux kernel's networking code. It can be triggered by attaching an fentry probe to ` sock release()` and the probe calling the `bpf get socket cookie()` helper, or by running `traceroute -I 1.1.1.1` on a freshly booted VM. A KASAN enabled kernel will log a slab-use-after-free error in ` sock gen cookie()`. The issue is caused by a dangling `sk` pointer when socket creation fails. To exploit this vulnerability, an attacker would need to be able to run privileged commands on the system, such as attaching an fentry probe or running `traceroute` with specific options. The vulnerability could potentially allow an attacker to gain elevated privileges or disrupt system operation. **Recommendations** To resolve this issue, it is recommended to update the Linux kernel to a version that includes the fix for this vulnerability. Specifically, the fix involves clearing the struct socket reference in `sk common release()` to cover all protocol families create functions. 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 5.16.0-rc5+ **Description** The vulnerability is related to the veth component of the Linux kernel, which fails to properly check for shared or cloned skbs when GRO is enabled on a veth device and TSO is disabled on the peer device. This can lead to a kernel bug and potentially cause a denial of service. The issue is addressed by skipping the GRO stage for shared or cloned skbs and trying to unclone the skbs before giving up. **Recommendations** To resolve the issue, update the Linux kernel to a version that includes the fix for this vulnerability. Specifically, versions prior to 5.16.0-rc5+ are affected, so updating to 5.16.0-rc5+ or later should resolve the issue. Note: The provided information does not specify the exact version that includes the fix, but it is clear that versions prior to 5.16.0-rc5+ are vulnerable.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the KVM (Kernel-based Virtual Machine) component of the Linux kernel, specifically with the x86/mmu (Memory Management Unit) module. The problem arises when the iterator is advanced after a restart due to yielding, which can cause the top-level SPTE (Shadow Page Table Entry) and its children to be skipped. This can lead to a use-after-free condition, resulting in data corruption and additional errors in the kernel. The vulnerability can be exploited by an attacker to potentially elevate their privileges in the system. **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 version 5.10.20-cloudflare-2021.3.1 **Description** The issue arises from the `efx->xdp tx queue count` being initially initialized to `num possible cpus()` and later used to allocate and traverse `efx->xdp tx queues` lookup array. However, not all array slots may be initialized with real queues during probing, resulting in a NULL pointer dereference when running commands like `ethtool -S <iface>`. This can lead to a kernel crash. **Recommendations** To resolve this issue, adjust `efx->xdp tx queue count` after probing to reflect the true value of initialized slots in `efx->xdp tx queues`. This adjustment ensures that the kernel accurately accounts for the number of queues available, preventing NULL pointer dereferences and subsequent crashes.