CVE-2026-98274
NoneCVSS
—
EPSS
0.2%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A Linux kernel networking issue could let two security features get in each other's way, potentially allowing encrypted traffic to be handled incorrectly.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Other
- Component
- OS kernel
- Class
- Misconfiguration
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw permits simultaneous use of PSP and TLS ULP, creating conflicts over the skb->decrypted flag and sk_validate_xmit_skb callback that can result in incorrect decryption state tracking or transmit validation bypass in the kernel networking stack.
Why it matters to the business
Systems relying on Linux kernel networking for encrypted traffic may encounter packet handling errors or weakened isolation between security features, raising the chance of subtle communication integrity issues that could affect availability or confidentiality during routine operations.
How an attack unfolds
An attacker configures or observes a connection where both PSP and TLS ULP are active, then crafts traffic that exercises the shared skb decrypted state or validation hook to induce misbehavior such as skipped checks or state corruption.
How to fix it
Apply a kernel update that enforces mutual exclusivity between PSP and TLS ULP via sk_has_decrypt_user checks; disable PSP on any socket using TLS or other ULPs until patched.
How to confirm the fix worked
Inspect kernel source or runtime configuration for sk_has_decrypt_user inclusion of all TCP ULPs and confirm PSP setup paths reject TLS coexistence; test socket creation under combined configurations to verify rejection.
Typical attack path
- Locate Linux systems exposing PSP-enabled sockets alongside TLS ULP
- Initiate or intercept connections that activate both protocol layers
- Send crafted packets targeting the conflicting decrypted flag or xmit validation path
- Trigger kernel-level mishandling leading to bypassed validation or resource exhaustion
How to detect it
Search kernel logs and network stack traces for messages referencing PSP/TLS conflicts, skb decrypted flag misuse, or sk_validate_xmit_skb errors; examine socket setup paths for concurrent ULP activation.
What your security team should do
- Prioritize kernel upgrades for any systems using PSP in production networking stacks
- Audit socket and ULP configurations to prevent concurrent PSP and TLS usage
- Incorporate PSP/TLS mutual-exclusion checks into network hardening baselines
- Schedule review within standard maintenance windows given low exploit maturity
The record
In the Linux kernel, the following vulnerability has been resolved: net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb() PSP conflicts with TLS ULP in its usage of both skb->decrypted and sk->sk_validate_xmit_skb(). Make PSP mutually exclusive with TLS ULP, the only other user of either of these. As other users of skb->decrypted come along, they can be added to sk_has_decrypt_user(). It would make sense to also assert that sk->sk_validate_xmit_skb() is also NULL in both of these setup paths for similar future proofing, but the PSP listener/sk_clone() path is still broken and it could be seen as a regression to not allow rx assoc to run on a child of a listener socket with PSP tx assoc state. Include all TCP ULPs in the sk_has_decrypt_user() check, even though TLS is the only one that conflicts with PSP via the decrypted bit. This is intentional because PSP was not designed to be used with ULPs. It is best to close off surface area that may make bugs reachable, until someone wishes to design and test an actual user of PSP with ULPs.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|