{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.176-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.94-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  slip: reject VJ receive packets on instances with no rstate array  slhc_init() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhc_init() is skipped, so comp-\u003erstate stays NULL and comp-\u003erslot_limit stays 0 (from the kzalloc of struct slcompress).  The receive helpers do not defend against that configuration. slhc_uncompress() dereferences comp-\u003erstate[x] when the VJ header carries an explicit connection ID, and slhc_remember() later assigns cs = \u0026comp-\u003erstate[...] after only comparing the packet's slot number to comp-\u003erslot_limit. Because rslot_limit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate.  The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val \u003e\u003e 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because /dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context:   Oops: general protection fault, probably for non-canonical        address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]  RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519)  Call Trace:   \u003cTASK\u003e   ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466)   ppp_input (drivers/net/ppp/ppp_generic.c:2359)   ppp_async_process (drivers/net/ppp/ppp_async.c:492)   tasklet_action_common (kernel/softirq.c:926)   handle_softirqs (kernel/softirq.c:623)   run_ksoftirqd (kernel/softirq.c:1055)   smpboot_thread_fn (kernel/smpboot.c:160)   kthread (kernel/kthread.c:436)   ret_from_fork (arch/x86/kernel/process.c:164)   \u003c/TASK\u003e  Reject the receive side on such instances instead of touching rstate. slhc_uncompress() falls through to its existing 'bad' label, which bumps sls_i_error and enters the toss state. slhc_remember() mirrors that with an explicit sls_i_error increment followed by slhc_toss(); the sls_i_runt counter is not used here because a missing rstate is an internal configuration state, not a runt packet.  The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (ppp_generic.c) still supplies tslots \u003e= 1, and slip.c always calls slhc_init(16, 16), so comp-\u003etstate remains valid and slhc_compress() continues to work.",
  "id": "DEBIAN-CVE-2026-45842",
  "modified": "2026-09-14T16:47:34.500048127Z",
  "published": "2026-05-27T11:16:23.600Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-45842"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-45842"
  ]
}