Linux kernel (net/smc): The SMC socket hashtables are re-initialised at the end of module init, after the protocol and

Impact

The SMC socket hashtables are re-initialised at the end of module init, after the protocol and socket family have already been registered. Sockets created in that window get their hash-list heads zeroed out from under them, leaving a corrupted list the kernel keeps walking and writing - memory corruption seeded at module load time.

Who can reach it

Local and unprivileged, and the trigger is the module autoload itself: socket(AF_SMC, ...) from an unprivileged process makes the kernel request the smc module through the net-pf-43 alias with no capability check, and a second thread racing socket() calls against that load lands in the window between sock_register() and the hashtable re-init. A tenant container can arrange this deliberately.

What to do

Boot a kernel carrying the fix commits (drops the redundant INIT_HLIST_HEAD calls). Interim: pre-load the smc module at boot on nodes that need it so no tenant can race a cold autoload, or blacklist it outright (install smc /bin/false) where SMC is unused.

References