Re: kern/60491: arp creates state for invalid messages

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60491; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/60491: arp creates state for invalid messages
Date: Mon, 9 Nov 2026 14:53:37 +0000

 > Date: Wed, 28 Oct 2026 15:59:31 +0100
 > From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 >=20
 > On Wed, Oct 21, 2026 at 04:00:52PM +0200, Manuel Bouyer wrote:
 > So it looks like that after m_makewritable(), we end up with a mbuf with =
 no
 > data (len =3D 0), but which is chained with our old mbuf.
 
 Yes, and I'm not sure why.  It would be nice if we could see the mbuf
 _before_ m_makewritable.  The twisty maze of loops and conditionals in
 m_makewritable, without any assertions or even comments about
 invariants, makes it hard to understand!
 
 > But the data here don't make much sense; these ethernet addresses
 > are unknown on my network and the ether type doesn't make sense
 > either.
 
 The mbuf contents do make sense as the _payload_ of an ethernet frame,
 because the (asynchronous) caller ether_input of arpintr has used
 m_adj to shave off the 14-byte ethernet header, which is why
 leadingspace=3D14 and (om->m_data - om->m_ext.buf) =3D 0xe =3D 14:
 
     680 void
     681 ether_input(struct ifnet *ifp, struct mbuf *m)
     682 {
 ...
     688 	struct ether_header *eh;
 ...
     714 	ehlen =3D sizeof(*eh);
 ...
     939 	/* Strip off the Ethernet header. */
     940 	m_adj(m, ehlen);
     941=20
     942 	switch (etype) {
 ...
     953 	case ETHERTYPE_ARP:
     954 		pktq =3D arp_pktq;
     955 		break;
 ...
     997 	if (__predict_false(!pktq_enqueue(pktq, m, h))) {
 
 https://nxr.netbsd.org/xref/src/sys/net/if_ethersubr.c?r=3D1.336#675
 
     265 void
     266 arp_init(void)
     267 {
     268=20
     269 	arp_pktq =3D pktq_create(ARP_MAXQLEN, arpintr, NULL);
 
 https://nxr.netbsd.org/xref/src/sys/netinet/if_arp.c?r=3D1.321#265
 
 Under this interpretation, we have:
 
 > ETHER: DST =3D 00:01:08:00:06:04
 > ETHER: SRC =3D 00:01:f4:cf:e2:d4
 > ETHER: TYPE =3D 0x4b00(unknown)
 > offset 0014: 84 e3 67 01
 > offset 0018: 00 00 00 00
 > offset 0022: 00 00 84 e3
 > offset 0026: 67 9e 00 00
 > offset 0030: 00 00 00 00
 > offset 0034: 00 00 00 00
 > offset 0038: 00 00 00 00
 > offset 0042: 00 00 00 00
 
 Data reformatted as struct arphdr:
 
 00 01                   uint16_t ar_hdr =3D 0x0001 =3D ARPHRD_ETHER
 08 00                   uint16_t ar_pro =3D 0x0800 =3D ETHERTYPE_IP
 06                      uint8_t ar_hln =3D 6 =3D sizeof(struct ether_addr)
 04                      uint8_t ar_pln =3D 4 =3D sizeof(struct in_addr)
 00 01                   uint16_t ar_op =3D 0x0001 =3D ARPOP_REQUEST
 f4 cf e2 d4 4b 00       uint8_t ar_sha[6], sender hw addr, OUI =3D Cisco[1]
 84 e3 67 01             uint8_t ar_spa[4], sender ip addr, 132.227.103.1
 00 00 00 00 00 00       uint8_t ar_tha[6], target hw addr, all zero (unknow=
 n)
 84 e3 67 9e             uint8_t ar_tpa[4], target ip addr, 132.227.103.158
 
 [1] https://regauth.standards.ieee.org/standards-ra-web/pub/view.html