7.8
CVE-2025-39873
- EPSS 0.02%
- Veröffentlicht 23.09.2025 06:15:46
- Zuletzt bearbeitet 20.01.2026 20:33:41
- Quelle 416baaa9-dc9f-4396-8d5f-8c081f
- CVE-Watchlists
- Unerledigt
In the Linux kernel, the following vulnerability has been resolved:
can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKB
can_put_echo_skb() takes ownership of the SKB and it may be freed
during or after the call.
However, xilinx_can xcan_write_frame() keeps using SKB after the call.
Fix that by only calling can_put_echo_skb() after the code is done
touching the SKB.
The tx_lock is held for the entire xcan_write_frame() execution and
also on the can_get_echo_skb() side so the order of operations does not
matter.
An earlier fix commit 3d3c817c3a40 ("can: xilinx_can: Fix usage of skb
memory") did not move the can_put_echo_skb() call far enough.
[mkl: add "commit" in front of sha1 in patch description]
[mkl: fix indention]Verknüpft mit AI von unstrukturierten Daten zu bestehenden CPE der NVD
Daten sind bereitgestellt durch National Vulnerability Database (NVD)
Linux ≫ Linux Kernel Version >= 4.19 < 5.15.194
Linux ≫ Linux Kernel Version >= 5.16 < 6.1.153
Linux ≫ Linux Kernel Version >= 6.2 < 6.6.107
Linux ≫ Linux Kernel Version >= 6.7 < 6.12.48
Linux ≫ Linux Kernel Version >= 6.13 < 6.16.8
Linux ≫ Linux Kernel Version6.17 Updaterc1
Linux ≫ Linux Kernel Version6.17 Updaterc2
Linux ≫ Linux Kernel Version6.17 Updaterc3
Linux ≫ Linux Kernel Version6.17 Updaterc4
Linux ≫ Linux Kernel Version6.17 Updaterc5
Debian ≫ Debian Linux Version11.0
| Typ | Quelle | Score | Percentile |
|---|---|---|---|
| EPSS | FIRST.org | 0.02% | 0.056 |
| Quelle | Base Score | Exploit Score | Impact Score | Vector String |
|---|---|---|---|---|
| nvd@nist.gov | 7.8 | 1.8 | 5.9 |
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
|
CWE-416 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.