Ignat Korchagin

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.

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()`.

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.

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.

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.

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.

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.

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.

A use-after-free issue exists in the networking code of the Linux kernel. The problem occurs when socket creation fails, leaving a dangling `sk` pointer. This can be triggered by attaching an fentry probe to the ` sock release()` function that calls the `bpf get socket cookie()` helper, and then executing a `traceroute -I` command on a freshly booted virtual machine. The flaw is located within the `sk common release()` function in the `net/core/sock.c` module. A use-after-free is a condition where a program continues to use a pointer after the memory it points to has been freed, which can lead to crashes or unauthorized data access.

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.

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.

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.