Vincent Mailhol

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A flaw exists in the Linux kernel’s etas es58x CAN driver where a partial allocation of RX URBs could lead to a memory leak. Specifically, the `es58x alloc rx urbs()` function, when failing to allocate the requested number of URBs but succeeding in allocating some, returns an error. This premature return skips necessary cleanup, resulting in leaked URBs. The driver is designed to handle partial URB allocation without issue, so partial allocation should not be considered a fatal error. The issue occurs because the `es58x open()` function returns early, skipping the 'free urbs' cleanup label. **Recommendations** Modify the `es58x alloc rx urbs()` function to return 0 if at least one URB has been allocated, restoring the intended behavior and preventing the leak in `es58x open()`.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a use-after-free vulnerability in the `pch can rx normal` function of the Linux kernel's CAN (Controller Area Network) driver. After calling `netif receive skb(skb)`, dereferencing `skb` is unsafe, especially when the `can frame cf` aliases `skb` memory, which is dereferenced just after the call to `netif receive skb(skb)`. This could potentially allow an attacker to impact the confidentiality, integrity, and availability of protected information. Reordering the lines solves the issue. **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 memory leak issue has been identified in the Linux kernel, specifically in the `m can read fifo()` function. This occurs when the second call to `m can fifo read()` fails, causing the function to jump to the `out fail` label and return without calling `m can receive skb()`. As a result, the `skb` previously allocated by `alloc can skb()` is not freed, leading to a memory leak. The issue was discovered using GCC -fanalyzer. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.