Date: Mon, 05 Jun 2023 14:46:04 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 271843] ppp can crash due to wrapping subtract in FsmRecvEchoReq() Message-ID: <bug-271843-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271843 Bug ID: 271843 Summary: ppp can crash due to wrapping subtract in FsmRecvEchoReq() Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: rtm@lcs.mit.edu Attachment #242617 text/plain mime type: Created attachment 242617 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D242617&action= =3Dedit tickle wrapping subtract in ppp's FsmRecvEchoReq() The follow HDLC frame sent to ppp causes it to dereference a null bp pointer: 7e c0 21 -- PROTO_LCP 09 ff 00 03 -- code=3D9 EchoReply, id=3D255, length=3D3 22 96 -- crc 7e The null bp arises in fsm_Input() in src/usr.sbin/ppp/fsm.c: bp =3D mbuf_Read(bp, &lh, sizeof lh); mbuf_Read() returns null if it consumes all of the data, which is the case for the above frame, since sizeof(lh) is four and only the four bytes 09 ff 00 03 are available. For the above frame, the null dereference happens in FsmRecvEchoReq(). That function has a length check that could have caught this problem: if (lcp && ntohs(lhp->length) - sizeof *lhp >=3D 4) { But the ntohs() returns unsigned 3, and the sizeof yields unsigned 4, so the subtract wraps to unsigned 0xffffffffffffffff, so the code in the if statement is executed and tries to dereference bp. Here's a backtrace from the attached demo: #0 0x000000000003e43c in FsmRecvEchoReq (fp=3D0x407f71e8, lhp=3D0x3fffffdd= 00,=20 bp=3D0x0) at fsm.c:962 #1 0x000000000003c974 in fsm_Input (fp=3D0x407f71e8, bp=3D0x0) at fsm.c:10= 96 #2 0x000000000004c4be in lcp_Input (bundle=3D0x97338 <bundle_Create.bundle= >,=20 l=3D0x407f7000, bp=3D0x407fd300) at lcp.c:1307 #3 0x000000000005002c in Despatch (bundle=3D0x97338 <bundle_Create.bundle>= ,=20 l=3D0x407f7000, bp=3D0x407fd300, proto=3D49185) at link.c:381 #4 0x000000000004fefe in link_PullPacket (l=3D0x407f7000,=20 buf=3D0x407fa140 "~\377\377~\377\365\275\276\275\177\371\365]\177\346\370\334\354\370\325\34= 6\205\351\326\345\370\370\374\374E|\365\234\314\314\326\346\365\305\346\377= \377~\300!\t\377", len=3D64, b=3D0x97338 <bundle_Create.bundle>) at link.c:323 #5 0x0000000000062b30 in physical_DescriptorRead (d=3D0x407f7f78,=20 bundle=3D0x97338 <bundle_Create.bundle>, fdset=3D0x410069c0) at physica= l.c:569 #6 0x000000000003221e in datalink_Read (d=3D0x407f2000,=20 bundle=3D0x97338 <bundle_Create.bundle>, fdset=3D0x410069c0) at datalin= k.c:474 #7 0x000000000001a6e2 in bundle_DescriptorRead ( d=3D0x97338 <bundle_Create.bundle>, bundle=3D0x97338 <bundle_Create.bun= dle>,=20 fdset=3D0x410069c0) at bundle.c:546 #8 0x00000000000548a0 in DoLoop (bundle=3D0x97338 <bundle_Create.bundle>) at main.c:661 #9 0x0000000000053d92 in main (argc=3D3, argv=3D0x3fffffeb70) at main.c:535 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271843-227>