[lwip-users] [lwip] Bug in pbuf_header() [patch]

[Duncan Palmer]

--Boundary_(ID_4Ujyk0GIjwB8BQBDacKNvg)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

The other day we discovered that using the sockets interface with UDP=20
connections doesn't work too well... a little bit of digging has revealed=
 the=20
problem is caused by the way pbuf_header() works. If a pbuf is of type=20
PBUF_ROM, its payload was not allocated by lwip, and so messing with the=20
payload pointer, as pbuf_header() does, to add space for headers is=20
dangerous.=20

What is happening in our case is that I call lwip_send() on a UDP socket.=
=20
This results in a pbuf flagged as PBUF_ROM being allocated, its payload=20
pointer pointing to the data I want to send. udp_send() calls pbuf_header=
()=20
to adjust the payload pointer so it can fit in a UDP header. The test in=20
pbuf_header():

if((u8_t *)p->payload < (u8_t *)p + sizeof(struct pbuf))=20

doesn't pick up on anything being wrong because the payload has a much hi=
gher=20
address than the pbuf, and so udp_send() happily goes off and overwrites=20
whatever came before my payload.=20

I've attached a patch against the latest CVS which adds a check for pbufs=
 of=20
type PBUF_ROM in pbuf_header() to fix this...

Dunk


--Boundary_(ID_4Ujyk0GIjwB8BQBDacKNvg)
Content-type: text/x-c; name=pbuf.c.patch; charset=iso-8859-1
Content-disposition: attachment; filename=pbuf.c.patch
Content-transfer-encoding: 8bit

--- lwip-cvs-20020529/src/core/pbuf.c   Wed May 29 15:00:16 2002
+++ tcpip/src/core/pbuf.c       Thu Aug  1 11:31:38 2002
@@ -443,6 +443,10 @@
 {
   void *payload;
 
+  /* If the payload wasn't allocated by lwip, we can't mess with it */
+  if (p->flags & PBUF_FLAG_ROM)
+      return -1;
+
   payload = p->payload;
   p->payload = (u8_t *)p->payload - header_size/sizeof(u8_t);
 

--Boundary_(ID_4Ujyk0GIjwB8BQBDacKNvg)--
[This message was sent through the lwip discussion list.]