Are You Affected by CVE-2019-14899? A Kernel Checklist

A scanner flags CVE-2019-14899 on a machine that has run a VPN for years, and the first instinct is to call the VPN broken. That is the wrong frame. The disclosed issue concerns an attacker on the victim's local network inferring information about certain TCP connections, not a website decrypting your tunnel.

Work through the four checks below in order. Each one either narrows the problem or ends the investigation.

Check 1: does the advisory cover your kernel

Look up your distribution's own record, not a blog's summary of a release date. The Ubuntu security page for this CVE lists the generic linux package for 18.04 LTS as vulnerable with the fix deferred, and it tracks other kernel packages on separate rows. Match your running release and kernel package to the right row. A version number that looks familiar is not a match.

A scanner hit means the identifier applies to something in your inventory. It does not mean a neighbouring device exploited the machine.

Check 2: who is the attacker in the model

The threat model assumes an adjacent attacker who can interact with the victim's access network. That is a specific position, not an arbitrary remote service that dislikes your exit node. If users connect from a coffee shop, the assumption is realistic; if they sit behind a managed corporate LAN, it is a different conversation.

Keep the local-network trust question open even when the tunnel is encrypted. Encryption answers a different question than adjacency does.

Check 3: which layer are you relying on

Correctly validated HTTPS supplies its own protection for application records, and TLS 1.3 authenticates that data end to end. It does not promise that an attacker cannot interrupt the underlying TCP connection. An application can therefore be safe to read while still being disruptable, and a disruption is not the same outcome as disclosure. Separate those two before you rate the risk.

That distinction matters for the write-up. It turns a vague claim that the VPN is insecure into a bounded statement about what an adjacent attacker could observe or interrupt.

Check 4: what mitigation did you actually deploy

The disclosure discusses routing and filtering mitigations and is explicit about their limits, including reverse-path filtering and asymmetric routes. Do not paste one sysctl value onto every VPN host and call it fixed. Reverse-path filtering interacts with routing, so a value that helps one topology can break another.

Verification is a command, not a checkbox. sysctl net.ipv4.conf.all.rp_filter shows the global value, and sysctl net.ipv4.conf.tun0.rp_filter shows the per-interface value that actually applies. Read both before and after any change.

Use the distribution guidance and your own routing design, then confirm the setting on the interface that carries the tunnel rather than in a file nobody loaded.

What to write down

Record the adjacent-attacker assumption, the running kernel package, the advisory row you matched, the mitigation you deployed and where it is applied, and the application protections in place. Add the date you checked the advisory, because those pages change. That combination is a defensible assessment.

An OS release date and a working VPN connection are not an assessment. They are two facts that happen to be easy to collect.