NC-SI treats the management controller as privileged, but the Linux
packet parser still needs to reject malformed or truncated replies
instead of walking past the skb or past its software filter tables.

This series closes six linked parser issues in net/ncsi:

  - short replies accepted before response header/checksum reads
  - GC/GP count fields exceeding software filter limits
  - GMCMA address counts exceeding payload-backed addresses
  - OEM response parsing that trusts vendor-specific payload offsets
  - short AEN packets accepted before AEN header/payload reads
  - GP payloads not checked against the consumed MAC/VLAN table bytes

The threat model here is a compromised BMC or management-channel MITM
on the NC-SI link. This is not internet-reachable remote input, so I am
sending it as a public [PATCH net] series with Cc: stable rather than
through security@.

Testing:

  - x86_64 defconfig with CONFIG_NET_NCSI=y and
    CONFIG_NCSI_OEM_CMD_GET_MAC=y:
    `make -C ~/src/linux-mainline O=~/src/build-ncsi-bmc-oob ARCH=x86_64
    -j$(nproc) net/ncsi/`
  - live x86_64/KASAN QEMU guest for the GP path: guest `virtio-net`
    registered with NCSI, `SP -> CIS -> GC -> GP` issued over the
    `NCSI` generic-netlink family, and a host tap responder returning
    matching NC-SI frames.  Without the series applied, a GP reply
    with mac_cnt=65 triggers
    `KASAN: slab-out-of-bounds in ncsi_rsp_handler_gp()`.  With the
    series applied, the same reply is rejected with `-ERANGE` and no
    KASAN report.
  - synthetic A/B userspace harness covering the other malformed-
    response cases: without the series, parsing either faults or
    corrupts adjacent state; with the series, each case is rejected
    or clamped at the parser boundary.

Impact / regression notes:

  - libclang call-graph query shows ncsi_validate_rsp_pkt() is only
    reached from ncsi_rcv_rsp() and ncsi_rsp_handler_dc(), so the new
    skb-length guard stays local to the response path.
  - cscope shows ncsi_aen_handler() is only reached from ncsi_rcv_rsp(),
    so the new AEN pulls stay local to AEN dispatch.
  - cscope on n_vids shows the downstream consumers are the response
    parser, the manage-side VLAN bitmap walkers, and ncsi-netlink's
    channel dump path, which is the surface this series intentionally
    tightens.

Michael Bommarito (6):
  net/ncsi: validate response packet lengths against the skb
  net/ncsi: bound filter table state to software limits
  net/ncsi: validate GMCMA address counts against the payload
  net/ncsi: validate OEM response payloads before parsing
  net/ncsi: validate AEN packet lengths against the skb
  net/ncsi: validate GP payload lengths before parsing

 net/ncsi/ncsi-aen.c |  30 +++++++++---
 net/ncsi/ncsi-rsp.c | 114 ++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 128 insertions(+), 16 deletions(-)

-- 
2.53.0

Hello Michael,

On Wed, Apr 22, 2026 at 12:03:36PM -0400, Michael Bommarito wrote:
> NC-SI treats the management controller as privileged, but the Linux
...
> The threat model here is a compromised BMC or management-channel MITM
> on the NC-SI link.

The subject of the cover letter and the quoted fragment suggest that
you have a wrong impression of where NC-SI links exist and what they
carry, let me try to clarify.

On motherboards with BMC (the management controller) there often is a
way for the BMC (dedicated SoC these days) to talk to the
host-controlled NIC via NC-SI which is basically RMII (normally used
to talk to Ethernet PHY but here it's used to talk to a whole big NIC)
on hardware level plus special kind of frames sent in-band for
(partial) control and monitoring of the NIC. And regular frames are
transmitted over the same set of signals, there's no dedicated channel
for any kind of management inside NC-SI.

The code your patches modify always runs only on the BMC itself, the
packets parsed are generated by a NIC directly.

So if anything, the threat model here is compromised NIC
firmware. MITMing sounds unlikely as that would require tricky
hardware modifications and if you can do that it's easier to put a
modified NIC instead.

The idea to not trust anything coming from a NIC too much is good in
general but please take the correct context into account when
reasoning about the patches.

On Wed, Apr 22, 2026 at 12:44 PM Paul Fertser <fercerpav@gmail.com> wrote:
> The code your patches modify always runs only on the BMC itself, the
> packets parsed are generated by a NIC directly.
>
> So if anything, the threat model here is compromised NIC
> firmware. MITMing sounds unlikely as that would require tricky
> hardware modifications and if you can do that it's easier to put a
> modified NIC instead.

Thanks for the correction, I definitely got that backwards!

Should I submit a v2 with the corrected notes or wait for any other
feedback / review on patch substance (assuming you think it's actually
worth merging)?

Thanks,
Mike Bommarito

Hello Michael,

On Wed, Apr 22, 2026 at 01:06:56PM -0400, Michael Bommarito wrote:
> On Wed, Apr 22, 2026 at 12:44 PM Paul Fertser <fercerpav@gmail.com> wrote:
> > The code your patches modify always runs only on the BMC itself, the
> > packets parsed are generated by a NIC directly.
...
> Should I submit a v2 with the corrected notes or wait for any other
> feedback / review on patch substance (assuming you think it's actually
> worth merging)?

So I see you got some interesting AI-generated review from the net
maintainer Jakub on 23rd Apr. That raises many important points so
please take time to go through them manually and respond. Once some
sort of consensus is reached feel free to send a v2.

Thank you for working on improving this dark corner of the Linux
networking, I hope server manufacturers will appreciate.

On Tue, May 12, 2026 at 8:30 AM Paul Fertser <fercerpav@gmail.com> wrote:
> So I see you got some interesting AI-generated review from the net
> maintainer Jakub on 23rd Apr. That raises many important points so
> please take time to go through them manually and respond. Once some
> sort of consensus is reached feel free to send a v2.

Hi Paul,
Thanks for the reminder!  I did some more homework after your comments
and started to dust off an old PowerEdge 1U in the basement to
properly test this, but realized that iDRAC probably won't give me
much to go on.  Do you have any recommendations about how best to test
this before I ship another turn?

Thanks,
Mike