Answer in brief
CVE-2026-74582 records a High severity (CVSS 7.8) vulnerability in packet: use consistent hard_header_len in non-ring send paths. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), 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.
CVSS is 7.8. 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), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <91f041451f967cd87ed722a8f43c0b767a64f1a0 || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <9052756290962ffb9a661bcf319e92dedaaedfed || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <5bb10753d428aadfc356a2bfe9acea09c82a62ec || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <b06b6fce6d7deaf7238e09b48ce3b1125ff41acd || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <03390aa32e669cc4ecd7d34108e2e1afc13d689d || d9fb8cc230b2a4757e9fe4f81468f81212d4deaa || 6190cce26e40bf71c4d375b21eea74bb07b6a0f3 || 01a658c1b9d4b5393c38d5a92d9112ab1425382a || 8809ae6747e760e6f1d2453ceb08c9bcc4939766 || >=4.4.133 <4.5 || >=4.9.103 <4.10 || >=4.14.44 <4.15 || >=4.16.12 <4.17 | 91f041451f967cd87ed722a8f43c0b767a64f1a0, 9052756290962ffb9a661bcf319e92dedaaedfed, 5bb10753d428aadfc356a2bfe9acea09c82a62ec, b06b6fce6d7deaf7238e09b48ce3b1125ff41acd, 03390aa32e669cc4ecd7d34108e2e1afc13d689d, 4.5, 4.10, 4.15, 4.17 |
| Linux/Linuxgeneric | 4.17 | Not reported |
| Linux/Linuxgeneric | >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <bcd4df60ac9481b1ceffdfe5ec38fe51dcaae812 || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <78a47127e33c340bc6d38dcc4552a094b4f5cc77 || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <142e287b3a25cfe909215177c23243e7fc5ae2b1 || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <91f041451f967cd87ed722a8f43c0b767a64f1a0 || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <9052756290962ffb9a661bcf319e92dedaaedfed || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <5bb10753d428aadfc356a2bfe9acea09c82a62ec || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <b06b6fce6d7deaf7238e09b48ce3b1125ff41acd || >=b84bbaf7a6c8cca24f8acf25a2c8e46913a947ba <03390aa32e669cc4ecd7d34108e2e1afc13d689d || d9fb8cc230b2a4757e9fe4f81468f81212d4deaa || 6190cce26e40bf71c4d375b21eea74bb07b6a0f3 || 01a658c1b9d4b5393c38d5a92d9112ab1425382a || 8809ae6747e760e6f1d2453ceb08c9bcc4939766 || >=4.4.133 <4.5 || >=4.9.103 <4.10 || >=4.14.44 <4.15 || >=4.16.12 <4.17 | bcd4df60ac9481b1ceffdfe5ec38fe51dcaae812, 78a47127e33c340bc6d38dcc4552a094b4f5cc77, 142e287b3a25cfe909215177c23243e7fc5ae2b1, 91f041451f967cd87ed722a8f43c0b767a64f1a0, 9052756290962ffb9a661bcf319e92dedaaedfed, 5bb10753d428aadfc356a2bfe9acea09c82a62ec, b06b6fce6d7deaf7238e09b48ce3b1125ff41acd, 03390aa32e669cc4ecd7d34108e2e1afc13d689d, 4.5, 4.10, 4.15, 4.17 |
Published upstream
Aug 21, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 27, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 21, 2026
In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.
Quoted source text, attributed separately from HOL analysis.