[PATCH net v2 0/2] net: dsa: mxl862xx: bound FDB dump walk and validate BRIDGE_ALLOC ids

[PATCH net v2 0/2] net: dsa: mxl862xx: bound FDB dump walk and validate BRIDGE_ALLOC ids

[memoriaru]

From: Zhang Hewei <memoriaru@foxmail.com>

Here is a v2 of the two mxl862xx robustness fixes, reworked after
the sashiko AI review.

Changes since v1 (https://lore.kernel.org/netdev/tencent_A56873DA4A296F5D794B6A5989A180A21C05@qq.com/):

- the walk limit is now checked after the "last" test: the walk
  needs one read more than the number of entries it reports, so
  checking before it rejected a correctly ended walk of a full table
- macro name, error message and comments say "conservative read
  limit" instead of "table capacity", which the exact value is not
- the "growing kernel memory without bound" wording is gone:
  entries whose port id does not match never reach the callback,
  which is exactly why the walk needs its own bound (the netlink
  dump skb never fills)
- BRIDGE_ALLOC validation now also rejects 0xffff (INVALID_HANDLE is
  documented but never defined; the MaxLinear GSW API uses 0xffff)
  and ids already in use, closing the duplicate-FID collapse
- Fixes: tags added (both issues come from the bridge offloading
  commit), self Reported-by trailers dropped, and the comment hunk
  that v1 carried in patch 2 is folded into patch 1

Base-commit: f47d223627f80cb7a1eb14c585fe6cb35de5e984

Zhang Hewei (2):
  net: dsa: mxl862xx: bound FDB dump walk with a read limit
  net: dsa: mxl862xx: validate the bridge id returned by BRIDGE_ALLOC

 drivers/net/dsa/mxl862xx/mxl862xx-api.h | 1584 +++++++++++++++++++++++
 drivers/net/dsa/mxl862xx/mxl862xx.c     |   57 +-
 drivers/net/dsa/mxl862xx/mxl862xx.h     |  343 +++++
 3 files changed, 1983 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/dsa/mxl862xx/mxl862xx-api.h
 create mode 100644 drivers/net/dsa/mxl862xx/mxl862xx.h

-- 
2.39.5 (Apple Git-154)

Re: [PATCH net v2 0/2] net: dsa: mxl862xx: bound FDB dump walk and validate BRIDGE_ALLOC ids

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net v2 0/2] net: dsa: mxl862xx: bound FDB dump walk and validate BRIDGE_ALLOC ids

[memoriaru]

From: Zhang Hewei <memoriaru@foxmail.com>

Hi,

Same context as the v1 thread, replying here for the v2 series:

Discovery: manual code inspection, while auditing this driver's
handling of device-controlled responses (the MAC table walk and the
BRIDGE_ALLOC reply).

Trigger status: the unbounded-walk mechanism was reproduced in-kernel
-- a self-contained module carrying the verbatim loop shape of
mxl862xx_port_fdb_dump() (device transport stubbed) built against the
official Ubuntu 6.8.0-71 headers and run under QEMU (TCG, unmodified
official vmlinuz) never terminated on its own (100M iterations logged;
a real table holds 4-16k entries). The reproduction is automated in
Docker and needs no special hardware. I do not have access to mxl862xx
hardware, so this exercises the driver-side loop logic, not a real
device.

The BRIDGE_ALLOC validation is logic-level: the driver consumed the
firmware-supplied id with only a transport status check, so the
reserved id 0 (which doubles as the "not allocated" sentinel and the
CPU-port bridge) was accepted verbatim. Whether compliant firmware can
be made to return such values is unknown without hardware; the checks
guard against firmware that breaks the API.

The v2 diffs themselves are small and mechanical and have not been
compile-tested against a full kernel tree (no hardware here); the
reproduction module compiles and runs on the official kernel.

Thanks,
Zhang Hewei

Re: [PATCH net v2 0/2] net: dsa: mxl862xx: bound FDB dump walk and validate BRIDGE_ALLOC ids

[Jakub Kicinski]

On Sat, 24 Oct 2026 05:03:22 +0800 memoriaru@foxmail.com wrote:
> Same context as the v1 thread, replying here for the v2 series:

Please add the relevant stuff to the cover letter when reposting.
The v2 did not apply so respin will be needed.
Also - please make sure you add appropriate people to CC on the cover
letter as well.
-- 
pw-bot: cr