CVE-2023-53272

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

net: ena: fix shift-out-of-bounds in exponential backoff

The ENA adapters on our instances occasionally reset. Once recently logged a UBSAN failure to console in the process:

UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/enacom.c:540:13 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117 Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017 Workqueue: ena enafwresetdevice [ena] Call Trace: <TASK> dumpstacklvl+0x4a/0x63 dumpstack+0x10/0x16 ubsanepilogue+0x9/0x36 __ubsanhandleshift_outofbounds.cold+0x61/0x10e ? __constudelay+0x43/0x50 enadelayexponentialbackoffus.cold+0x16/0x1e [ena] waitforresetstate+0x54/0xa0 [ena] enacomdevreset+0xc8/0x110 [ena] enadown+0x3fe/0x480 [ena] enadestroydevice+0xeb/0xf0 [ena] enafwresetdevice+0x30/0x50 [ena] processonework+0x22b/0x3d0 workerthread+0x4d/0x3f0 ? processonework+0x3d0/0x3d0 kthread+0x12a/0x150 ? setkthreadstruct+0x50/0x50 retfromfork+0x22/0x30 </TASK>

Apparently, the reset delays are getting so large they can trigger a UBSAN panic.

Looking at the code, the current timeout is capped at 5000us. Using a base value of 100us, the current code will overflow after (1<<29). Even at values before 32, this function wraps around, perhaps unintentionally.

Cap the value of the exponent used for this backoff at (1<<16) which is larger than currently necessary, but large enough to support bigger values in the future.