This is a correctness regression, not a novel bug. Commit 890e5198a6e5 consolidated separate integer flags into a bitfield in the raw_sock structure, and in doing so, converted what were naturally independent atomic writes into a read-modify-write sequence that requires synchronization. The raw_setsockopt() function operates without holding the socket lock, so concurrent calls on the same socket can race on the bitfield — one thread reads the flags, modifies them, and writes back while another thread is mid-operation, resulting in torn writes and corrupted state.
The fix adds a raw_setsockopt_locked() function and wraps the original with a locking layer, following the established kernel pattern. Apply the patch. But understand this: the fix addresses the obvious entry point, not necessarily the entire attack surface. The CAN subsystem has accumulated ioctl handlers, sysfs attributes, and backward-compatibility shims over its lifespan. Any path that reads raw_sock flags without equivalent locking is now a potential corruption vector — and you cannot verify completeness from the CVE record alone.
The CVSS 7.8 rating reflects a local race condition with constrained exploitability, which is defensible. However, the downstream impact is underweighted: corrupted bitfield state propagates to every ioctl path, error handler, and notification routine that consumes socket flags. The corruption doesn't stay contained to raw_setsockopt — it becomes input to packet routing, filter application, and device interaction decisions.
Audit your kernel version history. If you shipped kernels containing the bitfield refactoring but not the _locked() wrapper fix, treat this as a latent correctness bug with unknown exploitation history. The introduction-to-discovery window is the silent risk — you may have deployed vulnerable code without any triggering events, simply because the race window is narrow and the entry points are obscure.