CVE-2026-43377

What it actually does

This flaw causes the Linux kernel KSMBD SMB server to write SMB3 session, signing, encryption, and decryption key material to kernel/debug logs when KSMBD_DEBUG_AUTH logging is enabled. The weakness is not a memory corruption bug or unauthenticated remote code execution; it is credential/key material disclosure through overly verbose authentication debugging. If an attacker can trigger or observe an SMB3 session and also read the relevant kernel, debug, journald, syslog, console, or centralized log output, they may recover cryptographic keys that protect SMB traffic, undermining confidentiality and integrity for affected SMB sessions.

Why it matters to the business

Organizations using the in-kernel Linux SMB server with authentication debug logging enabled could unintentionally expose sensitive file-sharing session keys in logs. This can turn routine diagnostic logging into a data-protection risk, especially where kernel logs are broadly readable, forwarded to shared logging platforms, retained for long periods, or accessible to lower-privileged administrators. Although EPSS is currently low, the CVSS impact is high because exposed SMB signing and encryption keys can enable unauthorized reading or tampering with file-share traffic. It is not currently listed in CISA KEV and no public exploit maturity is reported, reducing immediate mass-exploitation pressure, but systems with KSMBD debug authentication logging enabled should still be treated as high priority.

How an attack unfolds

An attacker first needs a path to interact with an affected Linux host running KSMBD and SMB3. They authenticate or otherwise cause an SMB3 session to be established. If KSMBD_DEBUG_AUTH logging is enabled on the server, the vulnerable key-generation paths generate normal SMB3 signing and encryption/decryption keys and then write the raw key bytes into kernel/debug logging output. The attacker then obtains access to those logs, either through local log-read permissions, weak dmesg restrictions, compromised administrative credentials, a log-forwarding pipeline, exposed support bundles, or a centralized SIEM/log archive. Once the key material is recovered, the attacker may decrypt captured SMB session traffic or forge/tamper with traffic protected by SMB signing/encryption for the affected session, depending on traffic capture position and session context.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the KSMBD fix removing key logging from SMB3 signing and encryption key generation. Because no exact fixed version was provided, use the patched kernel packages from the applicable Linux distribution or kernel vendor advisory for CVE-2026-43377. As an immediate mitigation, disable KSMBD authentication debug logging and avoid enabling KSMBD_DEBUG_AUTH on production systems. Restrict access to kernel logs, journald, syslog, debugfs, crash dumps, support bundles, and centralized log platforms that may have ingested key material. Rotate SMB-related credentials and invalidate active SMB sessions where key exposure is suspected. If KSMBD is not required, disable the KSMBD service/module and use a patched, supported SMB service configuration.

How to confirm the fix worked

Confirm that the running kernel version includes the vendor patch for the KSMBD key-logging fix, not just that a package is installed. Verify that KSMBD authentication debug logging is disabled and that debugfs/kernel debug access is restricted. Check whether the KSMBD service or module is active on systems that provide SMB shares. Establish a test SMB3 session in a non-production validation environment and confirm that kernel, journald, syslog, and forwarded logs do not contain SMB3 session, signing, encryption, or decryption key bytes. Review retained logs and log-forwarding destinations for historical KSMBD authentication debug output before declaring the exposure remediated.

Typical attack path

1. Identify a Linux system exposing SMB service through the in-kernel KSMBD server.
2. Establish or trigger an SMB3 session against the server using valid low-privileged credentials or another available authenticated path.
3. Rely on KSMBD authentication debug logging being enabled on the target host.
4. Access kernel, debug, journald, syslog, console, crash, support-bundle, or centralized log output that contains KSMBD authentication debug records.
5. Extract SMB3 session, signing, encryption, or decryption keys from the logs.
6. Use the recovered key material to decrypt captured SMB traffic or attempt integrity bypass/tampering against traffic associated with the exposed session.

How to detect it

To determine whether this was already exploited or exposed, review whether KSMBD was enabled and whether authentication debug logging was active during the vulnerable period. Collect kernel ring buffer logs, journald entries, /var/log/kern.log, /var/log/messages, /var/log/syslog, console logs, crash dumps, support bundles, and centralized SIEM/log-forwarder archives. Search for KSMBD authentication debug output around SMB session establishment events and for references to SMB3 signing/encryption key generation. Pay special attention to logs containing hex dumps near KSMBD authentication messages or strings referencing session keys, signing keys, encryption keys, decryption keys, generate_smb3signingkey, or generate_smb3encryptionkey. Correlate any suspected key logging with SMB authentication events, client IP addresses, file-share access records, packet captures, and log-access audit trails to determine whether an attacker both generated sessions and had access to the exposed logs. Also review access to SIEM indices, log buckets, support bundles, and admin shells because exploitation depends on the ability to read the logged key material.

• KSMBD_DEBUG_AUTH
• generate_smb3signingkey
• generate_smb3encryptionkey
• ksmbd
• Session Key
• Signing Key
• Encryption Key
• Decryption Key
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/kernel/debug
• ksmbd.mountd

What your security team should do

• Inventory Linux systems running KSMBD and prioritize internet-facing, partner-facing, or broadly accessible SMB servers.
• Patch affected Linux kernels using the applicable vendor-fixed packages and reboot into the fixed kernel.
• Immediately disable KSMBD_DEBUG_AUTH or equivalent KSMBD authentication debug logging on production systems.
• Restrict read access to kernel logs, dmesg, journald, syslog, debugfs, crash dumps, support bundles, and centralized logging systems.
• Search historical logs for evidence that SMB3 key material was logged and determine retention, forwarding, and access scope.
• If key material exposure is found, treat affected SMB sessions as compromised, rotate relevant credentials, terminate active sessions, and review file-share access activity.
• Harden log-handling practices so secrets and cryptographic material are redacted, access-controlled, and retained only as necessary.
• Monitor vendor advisories because fixed kernel package versions vary by distribution and may be backported without a simple upstream version match.