{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:11",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "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"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  fbdev: bitblit: bound-check glyph index in bit_cursor()  bit_cursor() fetches the glyph under the cursor with  \tc = scr_readw(vc_pos); \tsrc = vc_font.data + ((c \u0026 charmask) * w * height);  where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer value comes directly from scr_readw() and may be larger than the current font's glyph count.  Syzkaller triggers this via vcs_write(). The Call Trace shows vcs_write() in vc_screen.c writing an arbitrary 16-bit value with writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via vcs_scr_writew() without checking charcount. The stored value is later read in bit_cursor() in bitblit.c.  When the font is changed from a font with 512 glyphs to a font with 256 glyphs, the screen buffer can retain characters with the high bit set from the previous mode, which could also produce the same out-of-bounds access.    BUG: KASAN: global-out-of-bounds in soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70   Read of size 16 at addr ffff800086c57970    Call Trace:    soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70    bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365    fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427    hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883    update_region+0x100/0x18c drivers/tty/vt/vt.c:669    vcs_write+0x8ec/0xaf0 drivers/tty/vt/vc_screen.c:685  bit_putcs_aligned() and bit_putcs_unaligned() already clamp the glyph index to vc_font.charcount. Apply the same clamp in bit_cursor() after extracting the attribute and masking, before indexing fontdata.  The fix completes the bounds checking started in commit 18c4ef4e765a (\"fbdev: bitblit: bound-check glyph index in bit_putcs*\"), which missed the cursor path.  This change should be safe because the clamp reuses the existing contract from fbcon: charcount is maintained under console_lock in con_font_set() and fbcon_font_set(), and hi_font_mask is cleared when switching from 512 to 256 glyphs. When stale screen data with high bits remains after a font switch, or when vcs_write() stores an arbitrary value, clamping the index to 0 prevents the out-of-bounds read without changing cursor semantics — the same fallback bit_putcs uses.",
  "id": "DEBIAN-CVE-2026-74635",
  "modified": "2026-08-23T04:47:33.942197999Z",
  "published": "2026-08-22T16:16:36.590Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-74635"
    }
  ],
  "upstream": [
    "CVE-2026-74635"
  ]
}