CVE-2026-46098

What it actually does

This is a Linux kernel use-after-free/double-teardown flaw in the CAIF networking subsystem. During CAIF socket reconnect/teardown handling, caif_connect() may disconnect and free an existing client after remote shutdown, but caif_free_client() leaves the adapter layer's service pointer stale. When the socket is later destroyed, caif_sock_destructor() can call caif_free_client() again and dereference the already-freed service object. The most likely outcome is a kernel crash or panic, causing local denial of service. The CVSS vector indicates local access with low complexity and low privileges, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Systems running affected Linux kernel versions with the CAIF subsystem available may be susceptible to local crashes caused by a low-privileged user or process. In business terms, this can interrupt workloads, trigger node reboots, disrupt services hosted on affected systems, and reduce reliability of shared Linux infrastructure. The current EPSS score is very low, the vulnerability is not listed in CISA KEV, and no public exploit maturity is reported, so broad opportunistic exploitation is not indicated; however, local denial-of-service flaws remain relevant on multi-user systems, container hosts, CI/build workers, desktop fleets, and any environment where untrusted local code can run.

How an attack unfolds

An attacker first needs the ability to execute code locally on a vulnerable Linux system with sufficient permissions to interact with CAIF sockets or the relevant networking interface. They create or manipulate a CAIF socket and drive the connection lifecycle into a state where a remote shutdown or disconnect path causes caif_connect() to tear down an existing CAIF client. That path calls caif_disconnect_client() and caif_free_client(), freeing the service layer while leaving a stale pointer in the adapter/client relationship. The attacker then causes the socket to be destroyed or otherwise triggers the destructor path. caif_sock_destructor() invokes caif_free_client() again, dereferencing the freed service pointer and causing a kernel fault. Successful exploitation is expected to crash the kernel or destabilize the host rather than provide code execution.

How to fix it

Apply a Linux kernel update that includes the CAIF fix clearing client/service links before releasing the service object. Because no specific fixed package versions were provided, use the corrected kernel releases from the relevant Linux distribution, appliance vendor, or upstream stable kernel branch once available. Prioritize systems where untrusted users, containers, build jobs, plugins, or third-party workloads can execute locally. If immediate patching is not possible, reduce exposure by disabling or removing CAIF support where it is not required, preventing loading of CAIF-related kernel modules, limiting local shell or workload execution by untrusted users, and enforcing standard hardening controls such as module-loading restrictions and least privilege. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the host continues running the vulnerable kernel.

How to confirm the fix worked

Confirm the running kernel version, not just the installed package version, and verify it maps to a vendor build containing the CAIF teardown fix. Check whether CAIF support is present or loaded using kernel configuration and module inventory methods such as reviewing /boot/config-$(uname -r), zcat /proc/config.gz where available, lsmod, modinfo, and /proc/net/protocols. Validate that patched source or vendor changelogs include the fix for clearing CAIF client/service pointers during teardown. After remediation, reboot and confirm uname -r reflects the fixed kernel. In test environments, exercise CAIF socket lifecycle behavior and confirm no kernel oops, panic, KASAN use-after-free report, or caif_sock_destructor crash occurs during repeated connect/disconnect/destroy sequences.

Typical attack path

1. Gain local code execution on a Linux system running an affected kernel with CAIF support available.
2. Create or access CAIF socket functionality from a low-privileged context, where permitted by the system configuration.
3. Trigger a CAIF connect/reconnect sequence after remote shutdown so the existing CAIF client is disconnected and freed.
4. Leave the stale service pointer in place after the first teardown.
5. Close or destroy the socket, or otherwise invoke the CAIF socket destructor path.
6. Cause a second free/dereference of the stale service pointer, leading to a kernel crash or denial of service.

How to detect it

Look for evidence of prior exploitation in kernel logs, system journals, crash dumps, and availability monitoring. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel entries, kdump/vmcore artifacts, pstore records, hypervisor reset logs, and EDR telemetry for local processes repeatedly opening network sockets before a crash. Search for kernel oops or panic traces involving CAIF teardown functions such as caif_free_client(), caif_sock_destructor(), caif_connect(), and caif_disconnect_client(). Also review logs for use-after-free reports from KASAN/KFENCE/slub_debug, general protection faults, NULL or invalid pointer dereferences, and crashes in net/caif code paths. Since exploitation requires local access, correlate crash timing with local user sessions, container executions, CI jobs, newly executed binaries, or repeated short-lived processes. There are no unique network indicators for this issue, and absence of CAIF-related crash traces does not prove non-exploitation if logs were rotated or the system rebooted without persistent crash capture.

• caif_free_client
• caif_sock_destructor
• caif_connect
• caif_disconnect_client
• net/caif
• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request
• RIP: caif_free_client
• RIP: caif_sock_destructor
• Call Trace: caif_free_client
• Call Trace: caif_sock_destructor
• /var/crash
• /sys/fs/pstore
• /proc/vmcore

What your security team should do

• Inventory Linux systems for affected kernel versions and whether CAIF support is enabled, built in, or loadable as a module.
• Prioritize patching multi-user systems, container hosts, developer workstations, CI/CD runners, VDI hosts, and other systems where untrusted local code may execute.
• Update to the vendor-provided fixed kernel and reboot affected hosts into the patched kernel.
• If CAIF is not required, disable CAIF-related modules or kernel support through distribution-supported mechanisms and module blocklisting until patching is complete.
• Monitor for kernel oops, panic, BUG, KASAN, or general protection fault logs referencing CAIF functions, especially caif_free_client, caif_sock_destructor, caif_connect, or caif_disconnect_client.
• Treat any unexplained local kernel crash on systems with CAIF enabled as potentially security-relevant and preserve logs and crash dumps for analysis.
• Because this vulnerability is not in KEV, has very low EPSS, and has no reported exploit maturity, handle it through normal kernel patch cycles unless the affected system permits untrusted local execution.