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

iavf: fix PTP use-after-free during reset

Commit 7c01dbfc8a1c5f ("iavf: periodically cache PHC time") introduced a worker to cache PHC time, but failed to stop it during reset or disable.

This creates a race condition where iavfresettask() or iavfdisablevf() free adapter resources (AQ) while the worker is still running. If the worker triggers iavfqueueptpcmd() during teardown, it accesses freed memory/locks, leading to a crash.

Fix this by calling iavfptprelease() before tearing down the adapter. This ensures ptpclockunregister() synchronously cancels the worker and cleans up the chardev before the backing resources are destroyed.

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

iavf: fix out-of-bounds writes in iavfgetethtoolstats()

iavf incorrectly uses realnumtxqueues for ETHSSSTATS. Since the value could change in runtime, we should use numtxqueues instead.

Moreover iavfgetethtoolstats() uses numactivequeues while iavfgetssetcount() and iavfgetstatstrings() use realnumtxqueues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1].

For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3:

Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S) iavfsetchannels() ... iavfallocqueues() -> numactivequeues = 8 iavfschedulefinishconfig() iavfgetssetcount() realnumtxqueues: 1 -> buffer for 1 queue iavfgetethtoolstats() numactivequeues: 8 -> out-of-bounds! iavffinishconfig() -> realnumtxqueues = 8

Use immutable numtxqueues in all related functions to avoid the issue.

[1] BUG: KASAN: vmalloc-out-of-bounds in iavfaddoneethtoolstat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800

CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x6f/0xb0 printreport+0x170/0x4f3 kasanreport+0xe1/0x180 iavfaddoneethtoolstat+0x200/0x270 iavfgetethtoolstats+0x14c/0x2e0 devethtool+0x3d0c/0x5830 devethtool+0x12d/0x270 devioctl+0x53c/0xe30 sockdoioctl+0x1a9/0x270 sockioctl+0x3d4/0x5e0 x64sysioctl+0x137/0x1c0 dosyscall64+0xf3/0x690 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... </TASK>

The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at devethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8