CVE-2024-39506: liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet

Severity: medium (CVSS 5.5 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.3% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2024-07-12 · updated 2026-06-17
Weakness: CWE-476

Description

In the Linux kernel, the following vulnerability has been resolved: liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Affected products

Linux kernel: from 4.15 before 4.19.317; from 4.20 before 5.4.279; from 5.5 before 5.10.221; from 5.11 before 5.15.162; from 5.16 before 6.1.95; from 6.2 before 6.6.35 — fixed in 4.19.317, 5.10.221, 5.15.162, 5.4.279, 6.1.95, 6.6.35

How to fix

Upgrade to a fixed version: Linux kernel 4.19.317, 5.10.221, 5.15.162, 5.4.279. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2024-39506 or the next vulnerability affects your stack