Re: [PATCH net] net-sysfs: update the queue counts in the unregistration path

Quoting Jakub Kicinski (2021-12-01 03:08:39)

On Mon, 29 Nov 2021 16:45:20 +0100 Antoine Tenart wrote:

quoted

When updating Rx and Tx queue kobjects, the queue count should always be
updated to match the queue kobjects count. This was not done in the net
device unregistration path and due to the Tx queue logic allowing
updates when unregistering (for qdisc cleanup) it was possible with
ethtool to manually add new queues after unregister, leading to 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

Updating the queue counts in the unregistration path solve the above
issue, as the ethtool path updating the queue counts makes sanity checks
and a queue count of 0 should prevent any update.

Would you mind pointing where in the code that happens? I can't seem 
to find anything looking at real_num_.x_queues outside dev.c and
net-sysfs.c :S

I read the above commit message again; it's not well explained... Sorry
for that.

The above trace was triggered using veths and this patch would solve
this as veths do use real_num_x_queues to fill 'struct ethtool_channels'
in its get_channels ops[1] which is then used to avoid making channel
counts updates if it is 0[2].

In addition, keeping track of the queue counts in the unregistration
path do help other drivers as it will allow adding a warning in
netdev_queue_update_kobjects when adding queues after unregister
(without tracking the queue counts in the unregistration path we can't
detect illegal queue additions). We could also not only warn for illegal
uses of netdev_queue_update_kobjects but also return an error.

Another change that was discussed is to forbid ethtool ops after
unregister. This is good, but is outside of the queue code so it might
not solve all issues.

(I do have those two patches, warn + ethtool, in my local tree and plan
on targeting net-next).

As you can see I'm a bit puzzled at how to fix this in the best way
possible[3]. I think the combination of the three patches should be good
enough, with only one sent to net as it does fix veths which IMHO is
easier to trigger. WDYT?

Thanks!
Antoine

[1] https://elixir.bootlin.com/linux/latest/source/drivers/net/veth.c#L222
[2] https://elixir.bootlin.com/linux/latest/source/net/ethtool/channels.c#L175
[3] Because the queue code does rely on external states.