CVE-2024-35841

What it actually does

The TLS sendmsg splice path fails to set full_record when user pages exceed MAX_MSG_FRAGS, causing the code to loop into an already-full msg_pl scatterlist and trigger a kernel warning in __sk_msg_free.

Why it matters to the business

Systems using TLS over splice operations may experience kernel warnings, potential send stalls, or reduced stability under sustained high-volume page transfers, increasing operational overhead on Linux-based network appliances and servers.

How an attack unfolds

An attacker crafts a sendmsg call with MSG_SPLICE_PAGES plus the MORE flag, supplying more pages than fit in the msg_pl scatterlist; the kernel aborts scatterlist setup without marking the record full, then continues attempting to append data and hits the warning on the next send iteration.

How to fix it

Update the Linux kernel to commit 02e368eb1444a4af649b73cbe2edd51780511d86 or later stable releases that contain the fix; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the running kernel contains commit 02e368eb1444a4af649b73cbe2edd51780511d86; exercise TLS splice paths with oversized msg_pl payloads and verify absence of the __sk_msg_free warning.

Typical attack path

1. Open a TLS socket and prepare a msg with MSG_SPLICE_PAGES
2. Set the MORE flag and supply more than MAX_MSG_FRAGS user pages
3. Trigger repeated sendmsg calls that fill the msg_pl
4. Observe kernel warning in __sk_msg_free on subsequent sends

How to detect it

Search kernel logs for __sk_msg_free warnings on systems running TLS; review audit logs for processes issuing splice sendmsg calls with the MORE flag around the time of any warnings.

What your security team should do

• Prioritize kernel upgrades on all systems exposing TLS splice workloads
• Monitor for __sk_msg_free warnings in kernel logs during the rollout window
• Test splice-heavy applications in staging before production deployment