PT-2026-27681 · Linux · Linux

Published

2026-03-25

·

Updated

2026-03-25

·

CVE-2026-23316

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.

Related Identifiers

CVE-2026-23316

Affected Products

Linux