Date: Tue, 31 May 2022 13:42:17 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 264372] bhyve e82545_transmit() can use uninitialized iovb[] content Message-ID: <bug-264372-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264372 Bug ID: 264372 Summary: bhyve e82545_transmit() can use uninitialized iovb[] content Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bhyve Assignee: virtualization@FreeBSD.org Reporter: rtm@lcs.mit.edu A Bhyve guest can cause e82545_transmit() to follow a path in which iovb[] and thus *iov are not initialized, but the code executes memcpy(hdrp, iov->iov_base, now); The guest can do this by creating a transmit descriptor with the following content: buffer_addr =3D (anything) lower.data =3D 0x21f00000 =3D CMD_DEXT | TXD_MASK | CMD_EOP upper.data =3D 0x00000100 =3D POPTS_IXSM This causes the descriptor type to be 0x20f00000 (i.e. not TYP_L) and the data length to be zero. As a result of the zero length, iov->* are never assigned to. Because of the EOP and IXSM, ckinfo[0].ck* are set, causing hdrlen to be 2, which causes e82545_transmit() to execute the code to prepend a header, which causes the memcpy() shown above to execute. This sequence also depends on what's on the stack in iovb[] (i.e. *iov), but often when I run it, iov->iov_len is a huge number. Sometimes iov->iov_base is an illegal pointer, sometimes a valid pointer to somewhere. --=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-264372-27103>