Re: [PATCH] net: atm: fix shift-out-of-bounds in __vcc_connect()

[Deepanshu Kartikey]

On Wed, Aug 26, 2026 at 5:34 PM Eric Dumazet <edumazet@xxxxxxxxxx> wrote:
>
> On Wed, Aug 26, 2026 at 1:59 PM Simon Horman <horms@xxxxxxxxxx> wrote:
> >
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > Full review at: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824024620.23485-1-kartikey406@xxxxxxxxx?part=1
> > ---
> > net: atm: fix shift-out-of-bounds in __vcc_connect()
> >
> > __vcc_connect() used dev->ci_range.vpi_bits and vci_bits directly as shift
> > amounts, which is a negative shift when those fields still hold the
> > ATM_CI_MAX (-1) sentinel.  The patch skips the VPI/VCI range check
> > entirely when either field equals ATM_CI_MAX.
> >
> > Closes: https://syzkaller.appspot.com/bug?extid=6665d3db5fef15914802
>
> A simpler fix would be something like
>
>    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 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 was defined in <uapi/linux/atmdev.h> as a sentinel
>     value for user-space ATM_SETCIRANGE requests, not as 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.
>
>  ...
>
>
> diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
> index 9600e1ec099304e465dddb00c36817339f538b3b..7b0c791399eaac9ebe00541a2c41d715f465a24f
> 100644
> --- a/drivers/usb/atm/usbatm.c
> +++ b/drivers/usb/atm/usbatm.c
> @@ -917,8 +917,8 @@ static int usbatm_atm_init(struct usbatm_data *instance)
>
>         instance->atm_dev = atm_dev;
>
> -       atm_dev->ci_range.vpi_bits = ATM_CI_MAX;
> -       atm_dev->ci_range.vci_bits = ATM_CI_MAX;
> +       atm_dev->ci_range.vpi_bits = 8;
> +       atm_dev->ci_range.vci_bits = 16;
>         atm_dev->signal = ATM_PHY_SIG_UNKNOWN;
>
>         /* temp init ATM device, set to 128kbit */

 Initially, I was thinking the same way. Thanks for reviewing it. I
will send patch v2 shortly

Thanks

Deepanshu