GHSA-3QFR-7VGQ-2884

Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-19 18:31
VLAI
Details

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

auxdisplay: line-display: fix OOB read on zero-length message_store()

linedisp_display() unconditionally reads msg[count - 1] before checking whether count is zero, so a write of zero bytes to the message sysfs attribute hits msg[-1]:

write(fd, "", 0);

-> message_store(..., buf, count=0)
   -> linedisp_display(linedisp, buf, count=0)
      -> msg[count - 1] == '\n'  ; OOB read

The kernfs write buffer for that store is a 1-byte allocation (kernfs_fop_write_iter() does kmalloc(len + 1) with len == 0), so msg[-1] is a 1-byte read before the slab object. On a KASAN-enabled kernel this trips an out-of-bounds report and panics; on stock kernels it silently reads adjacent slab data and, if that byte happens to be '\n', the following count-- wraps ssize_t 0 to -1 and is then passed to kmemdup_nul().

linedisp_display() is reached from the message_store() sysfs callback (drivers/auxdisplay/line-display.c message attribute, mode 0644) and from the in-tree initial-message setup with count == -1, so the OOB path is only userspace-triggerable via zero-byte writes; vfs_write() does not short-circuit on count == 0 and kernfs_fop_write_iter() dispatches the store callback regardless.

Guard the trailing-newline trim with a count check. The existing if (!count) block then takes the clear-display path unchanged.

Affects every auxdisplay driver that registers via linedisp_register() / linedisp_attach(): ht16k33, max6959, img-ascii-lcd, seg-led-gpio.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-63949"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T16:17:13Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nauxdisplay: line-display: fix OOB read on zero-length message_store()\n\nlinedisp_display() unconditionally reads msg[count - 1] before\nchecking whether count is zero, so a write of zero bytes to the\nmessage sysfs attribute hits msg[-1]:\n\n\twrite(fd, \"\", 0);\n\n\t-\u003e message_store(..., buf, count=0)\n\t   -\u003e linedisp_display(linedisp, buf, count=0)\n\t      -\u003e msg[count - 1] == \u0027\\n\u0027  ; OOB read\n\nThe kernfs write buffer for that store is a 1-byte allocation\n(kernfs_fop_write_iter() does kmalloc(len + 1) with len == 0),\nso msg[-1] is a 1-byte read before the slab object. On a\nKASAN-enabled kernel this trips an out-of-bounds report and\npanics; on stock kernels it silently reads adjacent slab data\nand, if that byte happens to be \u0027\\n\u0027, the following count--\nwraps ssize_t 0 to -1 and is then passed to kmemdup_nul().\n\nlinedisp_display() is reached from the message_store() sysfs\ncallback (drivers/auxdisplay/line-display.c message attribute,\nmode 0644) and from the in-tree initial-message setup with\ncount == -1, so the OOB path is only userspace-triggerable via\nzero-byte writes; vfs_write() does not short-circuit on\ncount == 0 and kernfs_fop_write_iter() dispatches the store\ncallback regardless.\n\nGuard the trailing-newline trim with a count check. The\nexisting if (!count) block then takes the clear-display path\nunchanged.\n\nAffects every auxdisplay driver that registers via\nlinedisp_register() / linedisp_attach(): ht16k33, max6959,\nimg-ascii-lcd, seg-led-gpio.",
  "id": "GHSA-3qfr-7vgq-2884",
  "modified": "2026-07-19T18:31:47Z",
  "published": "2026-07-19T18:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63949"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/197476b126010bac1b3199833c6966cd6f54c2a9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3859960daeb9b7b39b9847b5b0113bc6081eb735"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6ad4f75ef9f3372fce8cad494e789ac6a5507bef"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8776032fe989a9b5fc77f2de5e03e4adb44c630e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a7511dcd9dd4bc55d123f9b800c8a4ed2662e5c6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ca5b0781946d5083ceafa752141f47f085853620"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…