Dongli Zhang

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a missing verification for short frames in the tun xdp one() path, which could cause a corrupted skb to be sent downstack. Before the skb is transmitted, the tun xdp one-->eth type trans() may access the Ethernet header although it can be less than ETH HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata. The alternative path, tun get user(), already prohibits short frames with lengths less than the Ethernet header size from being transmitted for IFF TAP. This is to drop any frame shorter than the Ethernet header size. **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 CPU vector leak during CPU offline in the Linux kernel. The absence of IRQD MOVE PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. When the interrupt next triggers on the original CPU, the new affinity is enforced within ` irq move irq()`. A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. This leads to a CPU vector leak if the old CPU is outgoing before the interrupt triggers again on the new CPU. The `irq force complete move()` function is not invoked on the outgoing CPU to reclaim the old `apicd->prev vector` because the interrupt isn't currently affine to the outgoing CPU, and `irq needs fixup()` returns false. To address this issue, the invocation of `irq force complete move()` should be moved before the `irq needs fixup()` call to reclaim `apicd->prev vector`, if the interrupt is currently or used to be affine to the outgoing CPU. Additionally, the vector should be reclaimed in ` vector schedule cleanup()` as well, following a warning message. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.