{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.180-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.100-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.5-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  ring-buffer: Fix event length with forced 8-byte alignment  When RB_FORCE_8BYTE_ALIGNMENT is true, rb_calculate_event_length() reserves the space of event-\u003earray[0] for placing the data length and rb_update_event() stores the data length in event-\u003earray[0] accordingly. As a result the whole event length will add extra 4 bytes for sizeof(event.array[0]) unconditionally.  But ring_buffer_event_length() only subtracts the sizeof(event-\u003earray[0]) for events larger than RB_MAX_SMALL_DATA + sizeof(event-\u003earray[0]). As a result, small events on architectures with RB_FORCE_8BYTE_ALIGNMENT=true report a data length that is 4 bytes larger than expected.  To fix it, add the RB_FORCE_8BYTE_ALIGNMENT as a condition to subtract the size of that length field whenever RB_FORCE_8BYTE_ALIGNMENT is true.  This issue is observed in a riscv64 kernel with CONFIG_HAVE_64BIT_ALIGNED_ACCESS set to y, when we run ftrace selftest trace_marker_raw.tc, we get the weird log: for cases where the id is 1..100, the number of data field is 8*N, but once id exceeds 100, the number of data field becomes 8*N+4:  # 1 buf: 58 00 00 00 80 5e d1 63 (number of data field is 8*1)  ...  # a buf: 58 ...                  (number of data field is 8*2)  ...  # 64 buf: 58 ...                 (number of data field is 8*13)  # 65 buf: 58 ...                 (number of data field is 8*13+4)  After applying this change, the number of data field keeps being 8*N+4 consistently.",
  "id": "DEBIAN-CVE-2026-80876",
  "modified": "2026-09-14T16:47:29.622468892Z",
  "published": "2026-09-04T17:16:59.640Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-80876"
    }
  ],
  "upstream": [
    "CVE-2026-80876"
  ]
}