https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264372
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: [email protected]
Reporter: [email protected]
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 = (anything)
lower.data = 0x21f00000 = CMD_DEXT | TXD_MASK | CMD_EOP
upper.data = 0x00000100 = 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.
--
You are receiving this mail because:
You are the assignee for the bug.
