Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[BUG] drivers/net/ftmac100.c: device-reported RX frame length drives an unbounded `memcpy` into the fixed packet buffer (OOB write)

Aperta Adatta ai principianti
  • Qualcosa non va?
#21,111 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
70/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c
Ambito
embedded-iot, security

Direzione di ricerca

Inizia da ftmac100_receive() in drivers/net/ftmac100.c, poi controlla la maschera della lunghezza RX in include/nuttx/net/ftmac100.h e la dimensione del buffer dei pacchetti nel driver. Conferma la lunghezza massima accettata rispetto alla capacità di destinazione e confronta il percorso di rifiuto in drivers/net/encx24j600.c. Il lavoro è completato quando i frame troppo grandi o non validi vengono scartati in sicurezza e i controlli pertinenti del driver hanno esito positivo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Arch: all Area: Drivers OS: Linux Type: Bug
Description / Steps to reproduce the issue

In drivers/net/ftmac100.c (Faraday FTMAC100 10/100 MAC) the RX path memcpys the DMA-descriptor
frame length into the fixed packet buffer with no clamp against buffer capacity. The bound is
absent in all build configurations (not assert-gated). This is an out-of-bounds write of up
to ~1455 bytes of wire-controlled data past the per-interface packet buffer, into adjacent interface
buffers / BSS. The attacker is a link peer (or a malfunctioning/compromised MAC) that reports an
oversized RX frame length in the DMA descriptor status word.

ftmac100_receive() reads the RX frame length directly from the DMA descriptor and memcpys
that many bytes into the device packet buffer with no clamp against the buffer capacity:

/* drivers/net/ftmac100.c */
624   len  = FTMAC100_RXDES0_RFL(rxdes->rxdes0);   /* RX Frame Length from DMA descriptor */
625   data = (FAR uint8_t *)rxdes->rxdes2;         /* DMA RX buffer pointer */
...
635   memcpy(priv->ft_dev.d_buf, data, len);       /* no clamp vs d_buf capacity */
636   priv->ft_dev.d_len = len;

FTMAC100_RXDES0_RFL (include/nuttx/net/ftmac100.h:118) is ((des) & 0x7ff), i.e. a value
of 0..2047 taken verbatim from the descriptor status word the MAC/DMA writes.

The destination priv->ft_dev.d_buf is g_pktbuf[intf] (ftmac100.c:180,1353), sized
PKTBUF_SIZE = MAX_NETDEV_PKTSIZE + CONFIG_NET_GUARDSIZE. With the default
CONFIG_NET_ETH_PKTSIZE = 590 (include/nuttx/net/netconfig.h:207) the buffer is ~592 bytes,
so a reported length up to 2047 overflows it by up to ~1455 bytes.

There is no length check at all — not even a DEBUGASSERT — between the RFL read at :624
and the memcpy at :635. ftmac100_receive() runs off the RX interrupt work path for every
received frame; the length field is attacker/wire controlled and no userspace open()/read() is
required. Gated by CONFIG_FTMAC100 (e.g. QEMU/moxart, k210-class targets).

Why this is a bug (smoking gun): a sibling MAC driver rejects the oversized length.
drivers/net/encx24j600.c:1620-1628 reads the hardware RX status-vector length and drops the
frame when it is out of range:

else if (pktlen > (CONFIG_NET_ETH_PKTSIZE + 4) || pktlen <= (ETH_HDRLEN + 4))
  { nerr("Bad packet size dropped"); enc_rxrmpkt(...); NETDEV_RXERRORS(...); }

ftmac100 omits this equivalent bounds check on the same kind of device-reported RX length.

Note the precondition is modest: the destination is only ~592 bytes (default config) while the RFL
field allows up to 2047 and the DMA RX region is 2044 bytes, so any ordinary receivable frame larger
than ~592 bytes (a normal ~1000-byte Ethernet frame) already overflows via the unchecked memcpy —
no forged 2000-byte giant frame is required. The ~1455-byte figure is just the worst case
(2047 - 592).

Steps:

  1. Build with CONFIG_FTMAC100 and bring up the interface.
  2. From a link peer (or a malfunctioning/compromised MAC) deliver/report an RX frame larger than the
    ~592-byte d_buf — an ordinary ~1000-byte Ethernet frame suffices; up to 2047 is possible.
  3. ftmac100_receive() memcpys that many bytes into the ~592-byte g_pktbuf, overflowing it.

An AddressSanitizer build with the RFL mask (0x7ff), the 592-byte g_pktbuf, and an unclamped
memcpy of a normal oversize frame (e.g. len=1000) reports:

heap-buffer-overflow WRITE past the 592-byte region

Suggested fix: before the memcpy, reject or clamp the reported length, mirroring the
encx24j600 check:

if (len > CONFIG_NET_ETH_PKTSIZE || len <= ETH_HDRLEN)
  {
    NETDEV_RXERRORS(&priv->ft_dev);
    /* drop the frame, advance the descriptor */
  }
On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

ubuntu 22

NuttX Version

master

Issue Architecture

[Arch: all]

Issue Area

[Area: Drivers]

Host information

No response

Verification
  • I have verified before submitting the report.
Lingua principale
C
Stelle
4.1k
Fork
1.7k
Merge medio
1g 5h
PR unite (30g)
719

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/nuttx

Tutte le issue di apache/nuttx

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.