Bug 1225428 (CVE-2021-47517) - VUL-0: CVE-2021-47517: kernel: ethtool: do not perform operations on net devices being unregistered
Summary: VUL-0: CVE-2021-47517: kernel: ethtool: do not perform operations on net devi...
Status: NEW
Alias: CVE-2021-47517
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Major
Target Milestone: ---
Assignee: Michal Kubeček
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/407678/
Whiteboard: CVSSv3.1:SUSE:CVE-2021-47517:6.5:(AV:...
Keywords:
Depends on:
Blocks: 1225429
  Show dependency treegraph
 
Reported: 2024-05-28 07:27 UTC by SMASH SMASH
Modified: 2024-07-04 12:12 UTC (History)
4 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SMASH SMASH 2024-05-28 07:27:37 UTC
In the Linux kernel, the following vulnerability has been resolved:

ethtool: do not perform operations on net devices being unregistered

There is a short period between a net device starts to be unregistered
and when it is actually gone. In that time frame ethtool operations
could still be performed, which might end up in unwanted or undefined
behaviours[1].

Do not allow ethtool operations after a net device starts its
unregistration. This patch targets the netlink part as the ioctl one
isn't affected: the reference to the net device is taken and the
operation is executed within an rtnl lock section and the net device
won't be found after unregister.

[1] For example adding Tx queues after unregister ends up in NULL
    pointer exceptions and UaFs, such as:

      BUG: KASAN: use-after-free in kobject_get+0x14/0x90
      Read of size 1 at addr ffff88801961248c by task ethtool/755

      CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014
      Call Trace:
       dump_stack_lvl+0x57/0x72
       print_address_description.constprop.0+0x1f/0x140
       kasan_report.cold+0x7f/0x11b
       kobject_get+0x14/0x90
       kobject_add_internal+0x3d1/0x450
       kobject_init_and_add+0xba/0xf0
       netdev_queue_update_kobjects+0xcf/0x200
       netif_set_real_num_tx_queues+0xb4/0x310
       veth_set_channels+0x1c3/0x550
       ethnl_set_channels+0x524/0x610

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-47517
https://www.cve.org/CVERecord?id=CVE-2021-47517
https://git.kernel.org/stable/c/7c26da3be1e9843a15b5318f90db8a564479d2ac
https://git.kernel.org/stable/c/cfd719f04267108f5f5bf802b9d7de69e99a99f9
https://git.kernel.org/stable/c/dde91ccfa25fd58f64c397d91b81a4b393100ffa
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2021/CVE-2021-47517.mbox
https://bugzilla.redhat.com/show_bug.cgi?id=2283434
Comment 1 Michal Hocko 2024-05-28 09:17:02 UTC
Do I get it correctly that ethtool operations are privileged (guarded by CAP_NETADMIN) so this is not particularly comfortable to exploit?
Comment 3 Michal Kubeček 2024-05-28 09:57:04 UTC
(In reply to Michal Hocko from comment #1)
> Do I get it correctly that ethtool operations are privileged (guarded by
> CAP_NETADMIN) so this is not particularly comfortable to exploit?

Not all operations are privileged, essentially operations that change
something (setting parameters) are always privileged, operations which only
query the state are usually not (with few exceptions, e.g. querying wake
on LAN info which might show the "password"). It's not completely clear
if unprivileged "read-only" requests could be also abused.

But more important, since commit 5e1fccc0bfac ("net: Allow userns root
control of the core of the network stack.") in 3.8-rc1, CAP_NET_ADMIN is
checked via ns_capable() so that since the introduction of unprivileged
user namespaces (about the same time, IIRC 3.9 or so), even "read-write"
requests can be performed by anyone on a virtual network device like veth
if they create a namespace where they "are root".
Comment 4 Michal Hocko 2024-05-28 11:30:27 UTC
Thanks a lot Michal for clarification. So this indeed looks serious. Could you take care of this please?