In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: fix ARM64 alignment fault in multipath hash seed
`struct sysctl_fib_multipath_hash_seed` contains two u32 fields
(user_seed and mp_seed), making it an 8-byte structure with a 4-byte
alignment requirement.
In `fib_multipath_hash_from_keys()`, the code evaluates the entire
struct atomically via `READ_ONCE()`:
mp_seed = READ_ONCE(net->ipv4.sysctl_fib_multipath_hash_seed).mp_seed;
While this silently works on GCC by falling back to unaligned regular
loads which the ARM64 kernel tolerates, it causes a fatal kernel panic
when compiled with Clang and LTO enabled.
Commit e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire
when CONFIG_LTO=y") strengthens `READ_ONCE()` to use Load-Acquire
instructions (`ldar` / `ldapr`) to prevent compiler reordering bugs
under Clang LTO. Since the macro evaluates the full 8-byte struct,
Clang emits a 64-bit `ldar` instruction. ARM64 architecture strictly
requires `ldar` to be naturally aligned, thus executing it on a 4-byte
aligned address triggers a strict Alignment Fault (FSC = 0x21).
Fix the read side by moving the `READ_ONCE()` directly to the `u32`
member, which emits a safe 32-bit `ldar Wn`.
Furthermore, Eric Dumazet pointed out that `WRITE_ONCE()` on the entire
struct in `proc_fib_multipath_hash_set_seed()` is also flawed. Analysis
shows that Clang splits this 8-byte write into two separate 32-bit
`str` instructions. While this avoids an alignment fault, it destroys
atomicity and exposes a tear-write vulnerability. Fix this by
explicitly splitting the write into two 32-bit `WRITE_ONCE()`
operations.
Finally, add the missing `READ_ONCE()` when reading `user_seed` in
`proc_fib_multipath_hash_seed()` to ensure proper pairing and
concurrency safety.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can crash certain ARM64 systems when kernel code reads IPv4 multipath hash seed data compiled with Clang LTO. The available sources describe an availability risk, not confirmed data theft or privilege escalation. Exposure depends heavily on kernel version, architecture, and build configuration.
Executive priority
Treat this as a targeted availability risk for specific Linux ARM64 kernel builds, not a broad emergency based on current evidence. Patch through normal kernel maintenance, with faster handling for critical ARM64 infrastructure where kernel panic would disrupt services.
Technical view
The bug is an unsafe READ_ONCE() of an 8-byte struct with only 4-byte alignment. On ARM64 with Clang LTO, this can emit a 64-bit load-acquire instruction that faults if misaligned. The fix reads and writes the two u32 fields separately and adds a missing READ_ONCE() for user_seed concurrency safety.
Likely exposure
Likely exposure is limited to Linux kernels in the affected ranges, especially ARM64 builds using Clang LTO and IPv4 multipath hashing paths. The bundle does not prove broad default exposure across all Linux deployments.
Exploitation context
The source bundle does not cite active exploitation, and KEV is false. It describes a fatal kernel panic condition and a tear-write concurrency flaw, but provides no evidence of public exploit use, remote reachability, or privilege escalation.
Researcher notes
Evidence is strongest for root cause and patch direction because the CVE description explains the exact ARM64 alignment fault and concurrency fixes. Evidence is incomplete for exploitability, attacker prerequisites, affected distribution packages, and CVSS severity.
Mitigation direction
Track and apply the relevant Linux stable kernel fixes from vendor channels.
Prioritize ARM64 systems built with Clang LTO for review.
Confirm distribution kernel advisories before assuming backport status.
Avoid inventing local workarounds beyond vendor guidance.
Validation and detection
Inventory Linux kernel versions and ARM64 systems in scope.
Check whether kernels are built with Clang LTO enabled.
Review vendor advisories for backported fixes matching the cited commits.
Validate that patched kernels read and write seed fields separately.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23316 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Mar 25, 2026, 10:27 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.