CVE-2026-53233: netdev: fix double-free in netdev_nl_bind_rx_doit()

Published Jun 25, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

netdev: fix double-free in netdevnlbindrxdoit()

Sashiko flags that genlmsgreply() always consumes the skb. The error path calls nlmsgfree(rsp) so we can't jump directly to it. Let's not unbind, just propagate the error to the user. This is the typical way of handling genlmsgreply() failures. They shouldn't happen unless user does something silly like calling the kernel with an already-full rcvbuf.

Affected Software

11 affected components
Linux Linux kernel
Linux Linux kernel>=6.12<6.12.94
Linux Linux kernel>=6.13<6.18.36
Linux Linux kernel>=6.19<7.0.13
Linux Linux kernel=7.1-rc1
Linux Linux kernel=7.1-rc2
Linux Linux kernel=7.1-rc3
Linux Linux kernel=7.1-rc4
Linux Linux kernel=7.1-rc5
Linux Linux kernel=7.1-rc6
Linux Linux kernel=7.1-rc7

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Linux kernel to a version that resolves this vulnerability.

    Fixed in resolved

Event History

Jun 25, 2026
CVE Published
via MITRE·08:39 AM
Data Sourced
via MITRE·08:39 AM
Description
Data Sourced
via NVD·09:16 AM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What conditions are needed to trigger this issue?

An attacker needs local access and low privileges, as reflected by the CVSS vector. The affected error path is associated with a netlink reply failure; the description notes this should normally occur only when a caller does something such as invoking the kernel with an already-full receive buffer.

2

Is this likely to be reachable during normal operation?

The description characterizes genlmsg_reply() failures as atypical. It specifically identifies an already-full receive buffer as an example condition, so routine use is not indicated as the expected trigger.

3

What is the mitigation if an update cannot be applied immediately?

No supported configuration workaround is provided. Reducing untrusted local users' ability to invoke the relevant kernel netlink operation and avoiding intentionally exhausted netlink receive buffers may reduce exposure, but the described fix is the available remediation.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203