Haiyang Zhang

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The MANA driver's RX buffer alloc size is passed into napi build skb() to create SKB. The size needs to be aligned properly for better performance and atomic operations. Otherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic operations may panic on the skb shinfo(skb)->dataref due to alignment fault. To fix this bug, add proper alignment to the alloc size calculation. **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 vulnerability is related to the mana component of the Linux kernel, specifically with the function `mana get rxbuf cfg()` that aligns the RX buffer's DMA datasize to be a multiple of 64. This can cause a denial of service when a packet slightly bigger than mtu+14 is received, leading to `skb over panic`. The issue is resolved by removing the unnecessary alignment from the code, allowing oversized packets to be marked as CQE RX TRUNCATED by the NIC and dropped. **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 race condition on the per-CQ variable `napi work done` in the Linux kernel's net component. After calling `napi complete done()`, another CPU can start the napi thread and access the `cq->work done` variable, potentially causing memory corruption and panic if the value is set to >= budget. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited. Technical details about exploitation include: - The `napi complete done()` function is involved in the issue. - The `cq->work done` variable is accessed by multiple threads, leading to a race condition. - The `busy poll` feature can trigger the issue. **Recommendations** To fix this issue, save the per-CQ `work done` variable in a local variable before `napi complete done()`, so it won't be corrupted by a possible concurrent thread after `napi complete done()`. Also, add a flag bit to advertise to the NIC firmware: the NAPI `work done` variable race is fixed, so the driver is able to reliably support features like `busy poll`. At the moment, there is no information about a newer version that contains a fix for this vulnerability.