CVE-2015-7799

What it actually does

The slhc_init function in the Linux kernel SLIP driver fails to validate slot numbers supplied via the PPPIOCSMAXCID ioctl, allowing a NULL pointer dereference that triggers a kernel panic.

Why it matters to the business

Local users can force system crashes on affected Linux hosts, producing unplanned downtime, loss of in-flight work, and the need for manual restarts or failover.

How an attack unfolds

An attacker with local shell access identifies a vulnerable kernel, opens a PPPOE or SLIP interface, and issues a crafted PPPIOCSMAXCID ioctl containing an out-of-range slot identifier; the kernel dereferences a NULL pointer inside slhc_init and panics.

How to fix it

Upgrade the Linux kernel to a version containing the slhc_init bounds check (post-4.2.3 stable releases or distribution backports) and reboot affected systems.

How to confirm the fix worked

Confirm the running kernel version is newer than 4.2.3, then attempt the previously crashing ioctl in a test environment and verify no NULL dereference occurs; monitor dmesg for the absence of slhc-related oops messages.

Typical attack path

1. Obtain a local interactive shell on the target host
2. Locate a SLIP or PPP interface that uses the slhc code path
3. Issue a malicious PPPIOCSMAXCID ioctl with an invalid maximum CID value
4. Trigger the NULL dereference and observe the resulting kernel panic

How to detect it

Search kernel logs and crash dumps for oops or panic messages containing slhc_init or slip.c around the time of unexpected reboots; correlate with audit logs showing PPPIOCSMAXCID ioctl calls from untrusted processes.

• slhc_init
• PPPIOCSMAXCID
• NULL pointer dereference
• drivers/net/slip/slhc.c

What your security team should do

• Prioritize kernel upgrades on all internet-facing or multi-tenant Linux systems
• Restrict unprivileged local access where feasible until patches are applied
• Enable kernel crash-dump collection to capture future slhc_init panics for forensics