CVE-2026-23240

After calling cancel_delayed_work_sync() within tls_sk_proto_close(), there is a time window in which tx_work_handler() can be rescheduled by other code paths — for example, by Delayed ACK handling or ksoftirqd. In a race scenario: cpu1 thread checks the BIT_TX_SCHEDULED bit and schedules a new delayed task (schedule_delayed_work()) after cpu0 has already called cancel_delayed_work_sync() and considered the operation complete. As a result, tx_work_handler() may execute on an already freed TLS object, leading to use-after-free. The fix replaces cancel_delayed_work_sync() with a call to disable_delayed_work_sync(), which prevents the task from being rescheduled.

An attacker or malicious local user who can trigger appropriate code paths may compromise the confidentiality, integrity, and availability of the system — potentially leading to privilege escalation or kernel panic through exploitation of a use-after-free condition.

Apply patches available in the Linux kernel stable repository according to the references: commits 17153f154f80, 7bb09315f93d, 854cd32bc74f, and a5de36d6cee7. It is recommended to update to a kernel version containing the fix as soon as possible.

Linux kernels containing the vulnerable TLS subsystem implementation (tls_sw_cancel_work_tx()); specific versions indicated in the vendor references (patches available in the stable kernel repository).