DF-0562 — ng7_lmi STEPBY underflow (twin of DF-0554)

Verdict

NOT REPRODUCED LIVE — but bug confirmed in source (latent in a parallel source tree that is not built/shipped by default). The code is byte-for-byte identical to the DF-0554 pattern in the shipped sys/netgraph/lmi/ng_lmi.c, which I reproduced and patched live (see DF-0554 evidence pack).

Why not live-reproduced

sys/netgraph7/lmi/ng_lmi.c is built only when the kernel is compiled with options NETGRAPH7 AND options NETGRAPH7_LMI (see sys/conf/options:284,332 and sys/conf/files:1668+). The default X86_64_GENERIC kernel ships the OLDER netgraph (sys/netgraph/lmi/ng_lmi.c) as /boot/kernel/ng_lmi.ko. The two files have the same Makefile-target name (ng_lmi.ko) so only one can be installed at a time; the audit guest ships the older one (verified by strings /boot/kernel/ng_lmi.ko showing /usr/src/sys/netgraph/lmi/ng_lmi.c).

Standalone make in /usr/src/sys/netgraph7/lmi does succeed (the file itself is valid kernel C), but loading the resulting ng_lmi.ko would require also loading the netgraph7 base (netgraph7/netgraph/ng_base.c), which is not built/shipped either. Without an admin explicitly enabling NETGRAPH7 in a custom kernel, the path is dead code.

Source-level confirmation (trace)

The bug pattern in sys/netgraph7/lmi/ng_lmi.c is identical to DF-0554:

For a 1-2 byte mbuf, STEPBY(1) at :757 underflows packetlen from 0 to 0xFFFF (u_short). Subsequent *data reads at :760/:786/:794/:811 read past the mbuf into adjacent kernel heap. Same code path as DF-0554; same effect (heap OOB read + leak via NGM_LMI_GET_STATUS).

Reachability on default install

not reachable — netgraph7 stack is opt-in and not shipped. If a future release switches the default netgraph to netgraph7 (or an admin enables NETGRAPH7_LMI), this bug becomes live. The fix is warranted as defense-in-depth before that switch happens.

PoC

The DF-0554 PoC (df0554.c) triggers the bug on the shipped ng_lmi.ko with the identical code pattern; the same PoC would trigger this finding if ng7_lmi were loaded. See ../DF-0554/df0554.c and ../DF-0554/run.sh.

Recommended fix (validated compile-only)

fix.diff applies the same LMI_MIN_LENGTH guard to sys/netgraph7/lmi/ng_lmi.c:751 (just after packetlen = m->m_len;, before the first *data deref). Validated by:

1. patch -p4 < fix.diff → Hunk #1 succeeded at 750.
2. make in /usr/src/sys/netgraph7/lmi → builds cleanly (/usr/obj/usr/src/sys/netgraph7/lmi/ng_lmi.ko, 15824 bytes).
3. strings ng_lmi.ko | grep "too short" → the new log message is present.

Cannot run the PoC against this module on the audit guest because the netgraph7 base is not shipped; the fix validation is therefore not_testable (compile-only + traced close). The live behavior of an identical patch on the shipped twin is documented in DF-0554 (status: FIXED — baseline showed error at location -65533, patched shows too short (N)).

Kernel references (verified by source trace)

• sys/netgraph7/lmi/ng_lmi.c:88 — LMI_MIN_LENGTH defined, never used.
• sys/netgraph7/lmi/ng_lmi.c:544 — STEPBY macro, no underflow guard.
• sys/netgraph7/lmi/ng_lmi.c:741 — packetlen declared u_short.
• sys/netgraph7/lmi/ng_lmi.c:751 — packetlen = m->m_len;.
• sys/netgraph7/lmi/ng_lmi.c:757,783,791,806 — four STEPBY(1) sites.
• sys/netgraph7/lmi/ng_lmi.c:841 — IE loop while (packetlen >= 2).
• sys/conf/options:284 — NETGRAPH7 opt-in.
• sys/conf/files:1668+ — netgraph7 sources only built under NETGRAPH7_*.

Threat model

Same as DF-0554 (remote FR peer feeding crafted LMI over a serial link into an admin-configured ng_lmi node), but only on installations that opt into the netgraph7 stack. The bug is latent on default installs.

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.