Bug 2439900 (CVE-2026-23209)
| Summary: | CVE-2026-23209 kernel: macvlan: fix error recovery in macvlan_common_newlink() | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | Keywords: | Security |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A use-after-free vulnerability was found in the macvlan driver. When creating a macvlan interface in source mode fails after the source MAC has been added to the hash table (e.g., due to an invalid interface name), the hash entry still references the freed net_device structure. Subsequent packets matching that source MAC trigger use-after-free in macvlan_forward_source().
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2026021439-CVE-2026-23209-9ad6@gregkh/T This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2026:6036 https://access.redhat.com/errata/RHSA-2026:6036 This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2026:6037 https://access.redhat.com/errata/RHSA-2026:6037 This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2026:6153 https://access.redhat.com/errata/RHSA-2026:6153 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.6 Extended Update Support Via RHSA-2026:6164 https://access.redhat.com/errata/RHSA-2026:6164 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.4 Extended Update Support Via RHSA-2026:6310 https://access.redhat.com/errata/RHSA-2026:6310 This issue has been addressed in the following products: Red Hat Enterprise Linux 10 Via RHSA-2026:6632 https://access.redhat.com/errata/RHSA-2026:6632 This issue has been addressed in the following products: Red Hat Enterprise Linux 10.0 Extended Update Support Via RHSA-2026:6692 https://access.redhat.com/errata/RHSA-2026:6692 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Advanced Update Support Via RHSA-2026:6953 https://access.redhat.com/errata/RHSA-2026:6953 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Update Services for SAP Solutions Red Hat Enterprise Linux 8.8 Telecommunications Update Service Via RHSA-2026:6954 https://access.redhat.com/errata/RHSA-2026:6954 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions Red Hat Enterprise Linux 8.6 Telecommunications Update Service Via RHSA-2026:6961 https://access.redhat.com/errata/RHSA-2026:6961 This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.4 Extended Update Support Long-Life Add-On Via RHSA-2026:7003 https://access.redhat.com/errata/RHSA-2026:7003 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions Via RHSA-2026:7013 https://access.redhat.com/errata/RHSA-2026:7013 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions Via RHSA-2026:7100 https://access.redhat.com/errata/RHSA-2026:7100 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions Via RHSA-2026:9512 https://access.redhat.com/errata/RHSA-2026:9512 This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions Via RHSA-2026:9644 https://access.redhat.com/errata/RHSA-2026:9644 |
In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: <quote valis> The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). </quote valis> With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever "goto destroy_macvlan_port;" path is taken. Many thanks to valis for following up on this issue.