DF-3487 — ng_pppoe_rcvdata() PRIMED branch: heap OOB read via unvalidated

ph->length (DF-0414 sibling sink)

Kernel heap info leak (and adjacent-packet disclosure) in sys/netgraph7/pppoe/ng_pppoe.c ng_pppoe_rcvdata() PPPOE_PRIMED branch — the counterpart of DF-0414 which covered only ng_pppoe_rcvdata_ether().

Reproduce (guest, root)

# 1. build + load netgraph core, pppoe node, harness
cd /usr/src/sys/netgraph7/netgraph && make obj depend && make
kldload /usr/obj/usr/src/sys/netgraph7/netgraph/netgraph.ko
cd /usr/src/sys/netgraph7/pppoe && make obj depend && make
kldload /usr/obj/usr/src/sys/netgraph7/pppoe/ng_pppoe.ko
cd /root/ppsbx && make && kldload ./ppsbx.ko

# 2. create pppoe node, put session hook "svc1" into PPPOE_PRIMED
sysctl debug.ppsbx_cmd=1        # MKPEER eth0<->ethernet, CONNECT sess<->svc1,
                                # NGM_PPPOE_OFFER(svc1) => PRIMED

# 3. fire the crafted 32-byte PADI (ph->length=1024, SRV tag len=900)
sysctl debug.ppsbx_cmd=2

# 4. observe
sysctl debug.ppsbx_len                       # baseline: 944  (patched: 0)
sysctl -b debug.ppsbx_capture | od -A x -t x1 | less

Expected output (baseline, stock kernel)

• debug.ppsbx_len: 944 — the node emits a PADO whose Service-Name tag contains 896 bytes read out of bounds past the 32-byte PADI mbuf (the copy runs to m_data+924 of a header mbuf whose real payload ends at byte 32; ~668 bytes past the 256-byte mbuf object).
• Leaked bytes contain adjacent-mbuf-zone memory: kernel heap pointers (e.g. 08 29 63 17 01 f8 ff ff = 0xfffff80117632908 — mbuf m_next / m_data), mbuf headers, ifnet names (.vn1), and on an active-traffic boot a complete captured TCP packet (45 00 00 2c ... 0a 00 02 0f, seq numbers of the ssh session itself). See leak1.txt, leak_sample.txt (boot A rich sample), run.log.
• 3/3 runs identical per boot (leak1/2/3.txt).
• With fix.diff applied to ng_pppoe.c and the module rebuilt: debug.ppsbx_len: 0, empty capture, no crash (fixleak1/2.txt, fixrun.log).

Threat model

The PRIMED branch parses a PADI that the PPPoE server daemon sends back down its session hook. Any daemon that relays/echoes PADI payload from an unauthenticated LAN peer (relay/proxy deployments; the normal PADI→PADO flow re-embeds peer-supplied tags) delivers attacker-controlled ph->length to this path. Direct trigger also possible by the netgraph-controlling user (root via ngctl/ng_socket). Impact: kernel heap disclosure (pointers + cross-object data) and potential panic when the tag walk crosses an unmapped page (ph->length up to 0xFFFF).

Files

• ppsbx.c — harness kernel module (setup + fire + PADO capture)
• Makefile, run.sh, build.sh
• leak1/2/3.txt, leak_sample.txt, run.log, env.txt — baseline
• fixleak1/2.txt, fixrun.log — patched-module runs
• fix.diff — one-hunk fix (validated)
• VERDICT.md, manifest.json, verdict.json

DF-3487 — VERDICT

Status: reproduced (kernel heap info leak, deterministic, 3/3 + 3/3 runs across two boots) · Fix validated (same input cleanly rejected, 2/2 runs).

Root cause

ng_pppoe_rcvdata() (sys/netgraph7/pppoe/ng_pppoe.c:1176-1258) handles a PADI echoed by the PPPoE server daemon on a PPPOE_PRIMED session hook. It only guarantees m->m_len >= sizeof(struct pppoe_full_hdr) via m_pullup() (ng_pppoe.c:1194-1198) and then runs

get_tag(ph, PTT_SRV_NAME)   (ng_pppoe.c:1231)
get_tag(ph, PTT_HOST_UNIQ)  (ng_pppoe.c:1244)
scan_tags(sp, ph)           (ng_pppoe.c:1247)

get_tag()/scan_tags() bound their tag walk with end = &ph->tag[0] + ntohs(ph->length) (ng_pppoe.c:292-293) and carry the comment "assume we already sanity checked ph->length" (ng_pppoe.c:298-299) — but the PRIMED branch never does. The session branch of the same file does check (m->m_pkthdr.len < length → EMSGSIZE, ng_pppoe.c:1632), and DF-0414 established that the discovery branch of ng_pppoe_rcvdata_ether() (lines 1314-1619) omits it. This is the third sink with the identical omission.

Reproduction

Harness ppsbx.c (kernel module): 1. MKPEER ppsbx:eth0 <-> pppoe:ethernet; CONNECT ppsbx:sess <-> pppoe:svc1. 2. NGM_PPPOE_OFFER on "svc1" → session is PPPOE_PRIMED. 3. Fire a 32-byte PADI (header mbuf, no cluster): ph->length = 1024, Service-Name tag header claims 900 data bytes (8 real). Pre-send bytes verified in run.log: ... 88 63 11 09 00 00 04 00 | 01 01 03 84 | SERVNAME. 4. get_tag() accepts the tag (ptn = 24+900 = 924 <= end = 20+1024); make_packet() copies the "tag" (4+900 bytes) into the PADO, which is emitted on the ethernet hook and captured by the harness (debug.ppsbx_capture).

Baseline (stock ng_pppoe.ko, INVARIANTS kernel #0): * debug.ppsbx_len: 944 — PADO = 20(hdr) + 8(AC_NAME) + 904(SRV) + 12(COOKIE). * The SRV tag payload contains bytes [32..924) of the mbuf's address space: 896 bytes read past the real packet, ~668 bytes past the 256-byte mbuf object itself, out of the adjacent mbuf-zone slab. * Boot A sample (leak_sample.txt): kernel heap pointers 0xfffff80117632908 / 0xfffff80117632b08 at PADO offsets 0x110/0x310 (mbuf m_next/m_data), mbuf header fields (3a 00 00 00 02 80 00 00), and a complete captured TCP segment at 0x210 (45 00 00 2c ... 0a 00 02 02 -> 0a 00 02 0f, ports e4f4->0016 = the harness' own ssh session, seq a5 fc 00 53). * Boot B sample (leak1.txt): same 944-byte leak, ifnet name .vn1, sess_con pointer 0xfffff8008976bb00 in AC_COOKIE. * Identical across 3 runs per boot (leak1/2/3.txt, fixleak-… baselines).

No panic occurred with ph->length=1024 because the walk stayed inside the mbuf-zone slab; with ph->length up to 0xFFFF the walk (and scan_tags's garbage-driven tag headers) can run ~64KB past the object into unmapped kernel VA → page fault/panic (remote single-packet DoS potential, same as DF-0414's ether-side).

Fix validation

fix.diff adds the missing bound check to the PRIMED branch, mirroring the session branch (:1632):

if (m->m_pkthdr.len < (int)(sizeof(*wh) + length))
    LEAVE(EMSGSIZE);

Applied to the guest's /usr/src copy; ng_pppoe.ko rebuilt and reloaded (same stock kernel #0: DragonFly 6.5-DEVELOPMENT #0 … X86_64_GENERIC; ng_pppoe is a KLD on this system, so the module is the executing code for this path). Result (fixrun.log, fixleak1/2.txt): identical PADI input → no PADO emitted, debug.ppsbx_len: 0, capture empty, no crash, 2/2 runs. The patch was authored against the read-only sys/ tree (patch -p1 --dry-run clean) and never applied there.

Threat / impact ceiling

• Attacker: unauthenticated LAN peer whenever the server daemon echoes PADI content back down the PRIMED hook (relay/offer flow), or the netgraph-controlling user directly (root via ng_socket/ngctl).
• Primitive: out-of-bounds read of kernel heap (mbuf zone + neighbors), contents copied into a PADO observable by the attacker → kernel pointer disclosure (KASLR-defeat / heap-layout reconnaissance) and disclosure of unrelated in-flight packet data. Up to 0xFFFF-length walks → panic.
• No write primitive (make_packet copies INTO a correctly sized cluster and caps tag output at 1494 bytes).

Classification: Medium severity (daemon-relay precondition for the remote chain; direct trigger is root-gated), CWE-125, confidence certain.

kernel_refs: * sys/netgraph7/pppoe/ng_pppoe.c:1194 (only header pullup, no length check) * sys/netgraph7/pppoe/ng_pppoe.c:1231,1244,1247 (get_tag/scan_tags sinks) * sys/netgraph7/pppoe/ng_pppoe.c:292-331 (next_tag/get_tag walk bound) * sys/netgraph7/pppoe/ng_pppoe.c:1632 (session branch showing the missing check)

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.