CVE-2026-90055

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

usb: atm: usbatm: fix invalid ci_range initialization

syzbot reported a shift-out-of-bounds in __vcc_connect():

UBSAN: shift-out-of-bounds in net/atm/common.c:382:32

shift exponent -1 is negative

CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)

Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026

Call Trace:

<TASK>

dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120

ubsan_epilogue+0xa/0x30 lib/ubsan.c:233

__ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494

__vcc_connect+0x14b4/0x19c0 net/atm/common.c:382

vcc_connect+0x328/0x8f0 net/atm/common.c:498

pvc_bind+0x272/0x380 net/atm/pvc.c:52

__sys_bind+0x2e3/0x410 net/socket.c:1976

__x64_sys_bind+0x7a/0x90 net/socket.c:1979

...

ATM device ci_range fields (vpi_bits and vci_bits) represent the

number of bits supported for VPI and VCI addressing on the device.

net/atm/common.c directly uses these fields as bit shift counts:

vpi >> dev->ci_range.vpi_bits

vci >> dev->ci_range.vci_bits

1 << vcc->dev->ci_range.vpi_bits

1 << vcc->dev->ci_range.vci_bits

usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to

ATM_CI_MAX (-1), which is defined in <uapi/linux/atmdev.h> as a

sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit

count. Shifting by -1 is undefined behavior and triggers UBSAN

warnings.

ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits

for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as

done by solos-pci.