CVE-2026-46168

What it actually does

This is a local denial-of-service flaw in the Linux kernel MPTCP implementation. The vulnerable code path uses an atomic socket lock around timestamp-related socket option handling even though the timestamp helper functions may sleep. When a local privileged-enough user triggers the affected MPTCP socket option path, the kernel can hit a “scheduling while atomic” condition, potentially causing a kernel warning, panic, or system crash depending on kernel configuration and panic settings. The impact is availability loss only; the provided CVSS vector indicates no confidentiality or integrity impact and requires local access with low privileges.

Why it matters to the business

A user or process with local access to an affected Linux system may be able to crash the host, interrupting workloads, services, containers, or appliances that depend on that kernel. The risk is most important on multi-user systems, shared compute platforms, container hosts, CI/build infrastructure, and systems where untrusted local code can run. EPSS is very low and there is no known CISA KEV listing or reported ransomware use, so prioritize remediation through normal kernel patch cycles unless the system exposes local shell access or runs untrusted workloads.

How an attack unfolds

An attacker first needs local code execution on an affected Linux system. They then create or use an MPTCP socket and invoke timestamp-related socket option handling that reaches the vulnerable kernel path. Because the kernel holds an atomic-context fast socket lock while calling helpers that can sleep, the kernel may detect an invalid sleep in atomic context. On systems configured to panic on this class of kernel bug or warning, this can immediately crash the machine; otherwise it may still destabilize the host and degrade availability. There is no indication from the supplied data that this vulnerability is remotely exploitable, used by named threat actors, or publicly weaponized.

How to fix it

Apply a Linux kernel update that includes the MPTCP fix replacing the unsafe atomic fast socket lock with the sleepable lock_sock()/release_sock() sequence around timestamp socket option handling. No exact fixed package versions were provided, so use the fixed kernel packages from your Linux distribution or kernel vendor once available, and prioritize kernels that include the upstream mptcp timestamp sockopt scheduling fix. If immediate patching is not possible, reduce exposure by disabling or restricting untrusted local code execution, limiting shell access, isolating multi-tenant workloads, and disabling MPTCP where operationally feasible through distribution-supported sysctl/module configuration or kernel build options. Treat mitigations as temporary; the durable fix is a patched kernel followed by reboot into that kernel.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build that includes the MPTCP timestamp socket option scheduling fix. Validate package state with the platform’s package manager and confirm the active kernel after reboot with uname -r, because installing a kernel package alone is not sufficient if the host has not booted into it. Review vendor advisories, changelogs, or kernel commit history for references to the MPTCP fix for unsafe use of lock_sock_fast() around sock_set_timestamp() and sock_set_timestamping(). Where MPTCP is not required and has been disabled as a mitigation, verify the runtime configuration and test that MPTCP sockets cannot be created or used as expected. Avoid running proof-of-concept crash tests on production systems because successful validation may panic the host.

Typical attack path

1. Obtain local access to an affected Linux host, such as a shell, compromised service account, container escape-adjacent local execution context, or untrusted workload slot.
2. Run code that creates or manipulates an MPTCP socket.
3. Trigger timestamp or timestamping socket option handling on the MPTCP socket.
4. Cause the kernel to enter the unsafe lock/sleep path, producing a “scheduling while atomic” condition.
5. If kernel panic behavior is enabled or the condition is fatal, crash or destabilize the host, causing denial of service.

How to detect it

Look for evidence of kernel instability, warnings, oopses, or panics tied to MPTCP and timestamp socket option handling. Useful log sources include systemd journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, kdump/vmcore metadata, hypervisor reset events, and EDR telemetry showing local programs repeatedly creating MPTCP sockets or invoking socket options before a crash. Search for kernel messages such as “BUG: scheduling while atomic,” stack traces mentioning mptcp, lock_sock_fast, sock_set_timestamp, or sock_set_timestamping, and unexpected reboots shortly after those messages. Because this is a local denial-of-service bug, exploitation may leave little durable evidence beyond kernel logs and crash dumps; absence of logs does not prove non-exploitation if volatile logs were lost during panic or reboot.

• BUG: scheduling while atomic
• scheduling while atomic
• mptcp
• lock_sock_fast
• sock_set_timestamp
• sock_set_timestamping
• kernel panic
• Kernel panic - not syncing
• Oops
• Call Trace:
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• dmesg

What your security team should do

• Inventory Linux systems that support or enable MPTCP, especially shared servers, container hosts, developer workstations, CI runners, and multi-user platforms.
• Patch affected systems with vendor-supplied kernel updates and reboot to activate the fixed kernel.
• Prioritize remediation for systems where untrusted users, tenants, jobs, or containers can execute local code.
• If patching is delayed, temporarily disable MPTCP where feasible and restrict local code execution paths.
• Review kernel logs for prior “scheduling while atomic” events involving MPTCP or socket timestamp handling.
• Ensure kernel panic and crash dump settings align with operational requirements so crash evidence is retained for investigation.
• Track distribution advisories for exact fixed kernel package versions because none were provided in the input data.