CVE-2023-54090

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

ixgbe: Fix panic during XDP_TX with > 64 CPUs

Commit 4fe815850bdc ("ixgbe: let the xdpdrv work with more than 64 cpus") adds support to allow XDP programs to run on systems with more than 64 CPUs by locking the XDP TX rings and indexing them using cpu % 64 (IXGBEMAXXDP_QS).

Upon trying this out patch on a system with more than 64 cores, the kernel paniced with an array-index-out-of-bounds at the return in ixgbedeterminexdpring in ixgbe.h, which means ixgbedeterminexdpqidx was just returning the cpu instead of cpu % IXGBEMAXXDPQS. An example splat:

========================================================================== UBSAN: array-index-out-of-bounds in /var/lib/dkms/ixgbe/5.18.6+focal-1/build/src/ixgbe.h:1147:26 index 65 is out of range for type 'ixgbering *[64]' ========================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000058 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 65 PID: 408 Comm: ksoftirqd/65 Tainted: G IOE 5.15.0-48-generic #54~20.04.1-Ubuntu Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.5.4 01/13/2020 RIP: 0010:ixgbexmitxdpring+0x1b/0x1c0 [ixgbe] Code: 3b 52 d4 cf e9 42 f2 ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 b9 00 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 <44> 0f b7 47 58 0f b7 47 5a 0f b7 57 54 44 0f b7 76 08 66 41 39 c0 RSP: 0018:ffffbc3fcd88fcb0 EFLAGS: 00010282 RAX: ffff92a253260980 RBX: ffffbc3fe68b00a0 RCX: 0000000000000000 RDX: ffff928b5f659000 RSI: ffff928b5f659000 RDI: 0000000000000000 RBP: ffffbc3fcd88fce0 R08: ffff92b9dfc20580 R09: 0000000000000001 R10: 3d3d3d3d3d3d3d3d R11: 3d3d3d3d3d3d3d3d R12: 0000000000000000 R13: ffff928b2f0fa8c0 R14: ffff928b9be20050 R15: 000000000000003c FS: 0000000000000000(0000) GS:ffff92b9dfc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 000000011dd6a002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ixgbepoll+0x103e/0x1280 [ixgbe] ? schedclockcpu+0x12/0xe0 _napipoll+0x30/0x160 netrxaction+0x11c/0x270 _dosoftirq+0xda/0x2ee runksoftirqd+0x2f/0x50 smpbootthreadfn+0xb7/0x150 ? sortrange+0x30/0x30 kthread+0x127/0x150 ? setkthreadstruct+0x50/0x50 retfromfork+0x1f/0x30 </TASK>

I think this is how it happens:

Upon loading the first XDP program on a system with more than 64 CPUs, ixgbexdplockingkey is incremented in ixgbexdpsetup. However, immediately after this, the rings are reconfigured by ixgbesetuptc. ixgbesetuptc calls ixgbeclearinterruptscheme which calls ixgbefreeqvectors which calls ixgbefreeqvector in a loop. ixgbefreeqvector decrements ixgbexdplockingkey once per call if it is non-zero. Commenting out the decrement in ixgbefreeq_vector stopped my system from panicing.

I suspect to make the original patch work, I would need to load an XDP program and then replace it in order to get ixgbexdplockingkey back above 0 since ixgbesetuptc is only called when transitioning between XDP and non-XDP ring configurations, while ixgbexdplockingkey is incremented every time ixgbexdpsetup is called.

Also, ixgbesetuptc can be called via ethtool --set-channels, so this becomes another path to decrement ixgbexdplocking_key to 0 on systems with more than 64 CPUs.

Since ixgbexdplockingkey only protects the XDPTX path and is tied to the number of CPUs present, there is no reason to disable it upon unloading an XDP program. To avoid confusion, I have moved enabling ixgbexdplockingkey into ixgbesw_init, which is part of the probe path.