CVE-2025-38348 Affecting bpftool package, versions <0:5.15.0-312.187.5.el8uek
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-ORACLE8-BPFTOOL-12566403
- published9 Sept 2025
- disclosed10 Jul 2025
Introduced: 10 Jul 2025
CVE-2025-38348 (opens in a new tab)How to fix?
Upgrade Oracle:8 bpftool to version 0:5.15.0-312.187.5.el8uek or higher.
This issue was patched in ELSA-2025-20552.
NVD Description
Note: Versions mentioned in the description apply only to the upstream bpftool package and not the bpftool package as distributed by Oracle.
See How to fix? for Oracle:8 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()
Robert Morris reported:
|If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...]
The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun.
This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the "firmware" altered the value and no longer copies them.
The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default.
References
- https://linux.oracle.com/cve/CVE-2025-38348.html
- https://linux.oracle.com/errata/ELSA-2025-20551.html
- https://linux.oracle.com/errata/ELSA-2025-20552.html
- https://linux.oracle.com/errata/ELSA-2025-20553.html
- https://git.kernel.org/stable/c/0e4dc150423b829c35cbcf399481ca11594fc036
- https://git.kernel.org/stable/c/12134f79e53eb56b0b0b7447fa0c512acf6a8422
- https://git.kernel.org/stable/c/1f7f8168abe8cbe845ab8bb557228d44784a6b57
- https://git.kernel.org/stable/c/6d05390d20f110de37d051a3e063ef0a542d01fb
- https://git.kernel.org/stable/c/714afb4c38edd19a057d519c1f9c5d164b43de94
- https://git.kernel.org/stable/c/9701f842031b825e2fd5f22d064166f8f13f6e4d
- https://git.kernel.org/stable/c/da1b9a55ff116cb040528ef664c70a4eec03ae99
- https://git.kernel.org/stable/c/f39b2f8c1549a539846e083790fad396ef6cd802