GHSA-4J8X-6QX9-P4GC

Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-25 12:31
VLAI
Details

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

iio: accel: bmc150: clamp the device-reported FIFO frame count

__bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer

u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3];

which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits:

count = val & 0x7F;

so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget:

if (samples && count > samples)
    count = samples;

which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]:

bmc150_accel_fifo_transfer(data, (u8 *)buffer, count);

bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address.

Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[] is sized for, before the transfer, mirroring the watermark clamp already done in bmc150_accel_set_watermark(). A well-formed flush reports at most BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-64504"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-25T10:17:36Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: accel: bmc150: clamp the device-reported FIFO frame count\n\n__bmc150_accel_fifo_flush() copies the number of samples the device\nreports in its hardware FIFO into an on-stack buffer\n\n\tu16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3];\n\nwhich is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The\nframe count is read from the FIFO_STATUS register and only masked to its\n7 valid bits:\n\n\tcount = val \u0026 0x7F;\n\nso it can be 0..127. The only other limit applied to it is the optional\ncaller-supplied sample budget:\n\n\tif (samples \u0026\u0026 count \u003e samples)\n\t\tcount = samples;\n\nwhich does not constrain count on the flush-all path (samples == 0), and\nleaves it well above 32 whenever samples is larger. count samples are\nthen transferred into buffer[]:\n\n\tbmc150_accel_fifo_transfer(data, (u8 *)buffer, count);\n\nbmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a\nmalfunctioning, malicious or counterfeit accelerometer (or an attacker\ntampering with the I2C/SPI bus) that reports up to 127 frames writes up\nto 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up\nto 570 bytes that clobbers the stack canary, saved registers and the\nreturn address.\n\nClamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[]\nis sized for, before the transfer, mirroring the watermark clamp already\ndone in bmc150_accel_set_watermark(). A well-formed flush reports at most\nBMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.",
  "id": "GHSA-4j8x-6qx9-p4gc",
  "modified": "2026-07-25T12:31:38Z",
  "published": "2026-07-25T12:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64504"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2fe0531dd73eff1de0f2584cb77716d645e548d5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/35a3cd8fd65e15029eb90f1e510045b1bb071175"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3e766526827acd542bcd36c20c4d5f397e0f6521"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/89f4a4ca0ac3a933c750569a771c079a290b0721"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b5a9f521e0a49a0266200fd535b32a9668ecb33b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bfffc98f3de92e0f76be7c7b72e63ac1776a6dbc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ce0e1cae26096fe959a0da5563a6d6d5a801d5fb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d0e6d924a5484e005cae5aff6a0aa07a22f3c9ff"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.