Answer in brief
CVE-2025-39873 records a Unknown severity vulnerability in can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKB. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2025-39873 records a Unknown severity vulnerability in can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKB. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <e202ffd9e54538ef67ec301ebd6d9da4823466c9 || >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <1139321161a3ba5e45e61e0738b37f42f20bc57a || >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <94b050726288a56a6b8ff55aa641f2fedbd3b44c || >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <725b33deebd6e4c96fe7893f384510a54258f28f || >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <668cc1e3bb21101d074e430de1b7ba8fd10189e7 || >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <ef79f00be72bd81d2e1e6f060d83cf7e425deee4 | e202ffd9e54538ef67ec301ebd6d9da4823466c9, 1139321161a3ba5e45e61e0738b37f42f20bc57a, 94b050726288a56a6b8ff55aa641f2fedbd3b44c, 725b33deebd6e4c96fe7893f384510a54258f28f, 668cc1e3bb21101d074e430de1b7ba8fd10189e7, ef79f00be72bd81d2e1e6f060d83cf7e425deee4 |
| Linux/Linuxgeneric | 4.19 | Not reported |
Published upstream
Sep 23, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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]
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <e202ffd9e54538ef67ec301ebd6d9da4823466c9 || >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <1139321161a3ba5e45e61e0738b37f42f20bc57a || >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <94b050726288a56a6b8ff55aa641f2fedbd3b44c || >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <725b33deebd6e4c96fe7893f384510a54258f28f || >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <668cc1e3bb21101d074e430de1b7ba8fd10189e7 || >=1598efe57b3e768056e4ca56cb9cf33111e68d1c <ef79f00be72bd81d2e1e6f060d83cf7e425deee4 | e202ffd9e54538ef67ec301ebd6d9da4823466c9, 1139321161a3ba5e45e61e0738b37f42f20bc57a, 94b050726288a56a6b8ff55aa641f2fedbd3b44c, 725b33deebd6e4c96fe7893f384510a54258f28f, 668cc1e3bb21101d074e430de1b7ba8fd10189e7, ef79f00be72bd81d2e1e6f060d83cf7e425deee4 |
| Linux/Linuxgeneric | 4.19 | Not reported |
Published upstream
Sep 23, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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]
Quoted source text, attributed separately from HOL analysis.