CVE-2026-23316
Received Received - Intake
ARM64 Alignment Fault in Linux IPv4 Multipath Hash Seed

Publication date: 2026-03-25

Last updated on: 2026-04-23

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-25
Last Modified
2026-04-23
Generated
2026-05-07
AI Q&A
2026-03-25
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23316
EUVD
EUVD-2026-15263
Affected Vendors & Products
Showing 11 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.11
linux linux_kernel From 6.19 (inc) to 6.19.7 (exc)
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.13 (inc) to 6.18.17 (exc)
linux linux_kernel From 6.11.1 (inc) to 6.12.77 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's handling of the IPv4 multipath hash seed on ARM64 architectures. The issue arises because a structure containing two 32-bit fields (totaling 8 bytes) is read atomically using a macro that expects natural alignment. On ARM64, atomic load instructions require the data to be properly aligned. When compiled with Clang and Link Time Optimization (LTO), the compiler generates a 64-bit load instruction on a 4-byte aligned address, causing a fatal kernel panic due to an alignment fault.

Additionally, the write operation on this structure is flawed because it is split into two separate 32-bit writes, breaking atomicity and exposing a tear-write vulnerability. The fix involves reading and writing each 32-bit field separately with proper atomic operations to avoid alignment faults and ensure concurrency safety.


How can this vulnerability impact me? :

This vulnerability can cause a fatal kernel panic on ARM64 systems when the Linux kernel is compiled with Clang and LTO enabled. A kernel panic leads to a system crash, resulting in downtime and potential data loss.

Moreover, the tear-write vulnerability caused by non-atomic writes could lead to inconsistent or corrupted kernel state, which might be exploited or cause unpredictable system behavior.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is related to the Linux kernel's handling of the multipath hash seed structure on ARM64 architectures, specifically when compiled with Clang and LTO enabled.

Immediate mitigation steps include:

  • Update the Linux kernel to a version that includes the fix for this issue, which involves changing the READ_ONCE() and WRITE_ONCE() operations to operate on 32-bit members rather than the entire 8-byte structure.
  • Ensure that your kernel is not compiled with Clang and LTO enabled without the fix, as this combination triggers the alignment fault.
  • If updating the kernel immediately is not possible, avoid configurations or workloads that trigger the multipath hash seed reads or writes on ARM64 systems compiled with Clang LTO.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart