<Vulnerability name="CVE-2026-74677">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Moderate</ThreatSeverity>
    <PublicDate>2026-08-22T00:00:00</PublicDate>
    <Bugzilla id="2521362" url="https://bugzilla.redhat.com/show_bug.cgi?id=2521362" xml:lang="en:us">
kernel: net: usb: ipheth: fix carrier_work UAF on disconnect
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>7.0</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-825</CWE>
    <Details xml:lang="en:us" source="Mitre">
In the Linux kernel, the following vulnerability has been resolved:

net: usb: ipheth: fix carrier_work UAF on disconnect

ipheth_sndbulk_callback() re-arms the carrier-check work on any
non-zero URB status:

	else
		schedule_delayed_work(&amp;dev-&gt;carrier_work, 0);

Nothing ties that to the interface being up, so the work can be armed
again after ipheth_close() has already drained it, and stay armed
until the netdev whose private area embeds it is freed.

On unplug with a TX URB in flight, ipheth_disconnect() drains the work
through unregister_netdev() -&gt; ipheth_close() -&gt;
cancel_delayed_work_sync() and only then calls ipheth_kill_urbs().
usb_kill_urb() completes the in-flight TX URB with -ENOENT, so
ipheth_sndbulk_callback() runs after the drain and re-arms
carrier_work.

The same completion also re-arms the work if the interface is only
brought down while a TX URB is in flight, and
ipheth_carrier_check_work() then keeps re-queueing itself once a
second. unregister_netdev() does not call ipheth_close() for an
already-down interface, so nothing drains it on the later unplug
either.

In both cases free_netdev() frees the netdev while carrier_work is
still pending, and ipheth_carrier_check_work() dereferences freed
memory.

Tie the work to the interface state instead of chasing the completion:
disable it in ipheth_close() and enable it in ipheth_open(), so a
schedule_delayed_work() from the URB completion is a no-op whenever
the interface is not up. disable_delayed_work_sync() also waits for a
running instance, so it fully replaces the cancel_delayed_work_sync()
it takes the place of. The work starts out disabled in ipheth_probe()
so the enable/disable counts balance from the first open.

Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and
raw-gadget standing in for the device, driving the second path above (the
interface is already down, so unregister_netdev() does not call
ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in
__run_timers(), freed by ipheth_disconnect() and re-armed from
ipheth_sndbulk_callback() via queue_delayed_work_on(). The
same trigger on a kernel differing only by this patch reports 0 of 15,
and the carrier check still functions across open/close cycles.

The reproducer needs an attached USB device that stops draining bulk OUT,
plus a link down and unplug, driven as root. It is not a privilege
boundary crossing and no exploit primitive was developed.

Found by 0sec (https://0sec.ai).
    </Details>
    <Details xml:lang="en:us" source="Red Hat">
A flaw was found in the Linux kernel's `ipheth` USB network driver. This vulnerability allows a local attacker with root privileges, using a specially crafted USB device, to trigger a Use-After-Free (UAF) condition. This occurs when the `carrier_work` mechanism attempts to access memory that has already been freed after the network interface has been closed or disconnected. Successful exploitation can lead to a system crash, resulting in a denial of service.
    </Details>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:10">
        <ProductName>Red Hat Enterprise Linux 10</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:6">
        <ProductName>Red Hat Enterprise Linux 6</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-74677
https://nvd.nist.gov/vuln/detail/CVE-2026-74677
https://lore.kernel.org/linux-cve-announce/2026082231-CVE-2026-74677-ecca@gregkh/T
    </References>
</Vulnerability>