{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.113-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  ALSA: line6: reject oversized playback packets  Each playback URB is handed a slice of out.buffer that is exactly LINE6_ISO_PACKETS * max_packet_size_out bytes, sized from the OUT endpoint, but the number of bytes written into that slice is never compared against it.  submit_audio_out_urb() takes the frame count from prev_fsize, which audio_in_callback() derived from the *IN* endpoint's received packet length, and rescales it with the playback frame size; when prev_fsize is still zero it synthesizes a length from the sample rate instead.  On a device declaring a large IN wMaxPacketSize and a small OUT wMaxPacketSize, the resulting memcpy(), or the memset() when the playback stream is idle, runs past its slice and, as the reproducer below shows, beyond the allocation.  usb_submit_urb() is not a backstop.  max_packet_size_out comes from usb_maxpacket(), which returns only the low 11 bits of wMaxPacketSize, while USB core validates a high-speed isochronous length against that base scaled by usb_endpoint_maxp_mult().  A length of up to three times the allocated slice is therefore accepted, and even a rejected URB is only rejected after the write.  Reject a packet that does not fit the slice the driver allocated for it. Clamping it instead would silently shorten the capture-derived rate feedback and desynchronize the two streams.    BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb (sound/usb/line6/playback.c:229)   Write of size 1024 at addr ffff888100bbd400 by task kworker/1:2/5002   Workqueue: events line6_startup_work   Call Trace:    __asan_memcpy (mm/kasan/shadow.c:106)    submit_audio_out_urb (sound/usb/line6/playback.c:229)    line6_submit_audio_out_all_urbs (sound/usb/line6/playback.c:291)    line6_stream_start (sound/usb/line6/pcm.c:194)    line6_pcm_acquire (sound/usb/line6/pcm.c:337)    line6_startup_work (sound/usb/line6/driver.c:728)    process_one_work (kernel/workqueue.c:3396)    worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560)    kthread (kernel/kthread.c:436)    ret_from_fork (arch/x86/kernel/process.c:158)    ret_from_fork_asm (arch/x86/entry/entry_64.S:245)    The buggy address belongs to the object at ffff888100bbd400    which belongs to the cache kmalloc-256 of size 256   The buggy address is located 0 bytes inside of    allocated 256-byte region [ffff888100bbd400, ffff888100bbd500)",
  "id": "DEBIAN-CVE-2026-98836",
  "modified": "2026-10-19T04:47:44.485940792Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-98836"
    }
  ],
  "upstream": [
    "CVE-2026-98836"
  ]
}