data built 2026-10-19T13:16:53Z

Look up another CVE · open CVE-2026-72019 in the interactive tracker

CVE-2026-72019

macsec: don't read an unset MAC header in macsec_encrypt()

7.3 EPSS 0.2% AV:L

Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-72019 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

ReleaseStatus VersionWhat this means
Debian 12bookwormfixed6.1.180-1Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixiefixed6.12.100-1Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts.
Debian 14forkyfixed7.1.5-1Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesidfixed7.1.5-1Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d ("macvlan: do not assume mac_header is set in macvlan_broadcast()") for exactly this purpose.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/net/macsec.c

What this is
NETWORKING [MACSEC]MAINTAINERS section matched on drivers/net/macsec.c · netdev@vger.kernel.org · Maintained
Kernel module
macsec

Check it on the machine

grep -w CONFIG_MACSEC /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w macsec

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

  • bookworm, trixie, forky, sidm
m
a loadable module on every flavour - check lsmod, can be blacklisted
Build switch
CONFIG_MACSEC

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published
2026-08-15 (2 months ago)source
CVSS
7.3 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:Hsource recompute it
Attack vector
local (AV:L)source
EPSS
0.17%, higher than 6.2% of all CVEssource
CISA KEV
not listedthe KEV catalogue
Debian urgency
not yet assignedsource
Subsystem
drivers/net

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

IntroducedFixed inCommit
4.65.10.265b6cec6187b86
4.65.15.2163adea1b1c04b
4.66.1.178dc9ffa1905e7
4.66.6.145f21fa533a3ed
4.66.12.97e17a42199824
4.66.18.402cf10d042562
4.67.1.5c39087ad0b97
4.67.2f5089008f90c

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local
The bug is reached only via local AF_PACKET SOCK_RAW transmit with PACKET_QDISC_BYPASS to a macsec netdev; it is a TX-only ndo_start_xmit path, not reachable from remote network packet reception.
AC:LAttack complexity, low
An attacker fully controls the trigger: create a raw packet socket with a specific ethertype, enable PACKET_QDISC_BYPASS, and send a frame on a configured macsec interface with protect_frames enabled.
PR:LPrivileges required, low
Exploitation requires CAP_NET_RAW for AF_PACKET and CAP_NET_ADMIN to create/configure a macsec netdev and TX SA keys; both are obtainable by an unprivileged user inside a user namespace with delegated capabilities.
UI:NUser interaction, none
No victim interaction is required; the attacker sends crafted frames directly through the vulnerable transmit path without any action from another user or administrator.
S:UScope, unchanged
Impact is confined to kernel heap disclosure and possible kernel crash on the same host; it does not cross a VM, container, or IOMMU security boundary to affect a separate authority.
C:HConfidentiality impact, high
eth_hdr(skb) performs a 12-byte slab out-of-bounds heap read when mac_header is unset; the leaked kernel memory is copied into the transmitted frame's source/destination MAC fields, disclosing sensitive heap contents.
I:LIntegrity impact, low
The memmove in macsec_encrypt() overwrites the outgoing frame's 12-byte Ethernet addresses with leaked heap data, causing unauthorized modification of transmitted packet contents without arbitrary kernel memory writes.
A:HAvailability impact, high
Reading from skb->head plus unset mac_header offset 65535 causes a slab out-of-bounds access that KASAN flags and can page-fault into a kernel oops or panic when macsec_encrypt() runs on affected builds.