| Message ID | 20220825092910.23922-1-f.ebner@proxmox.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] hw/net/vmxnet3: allow VMXNET3_MAX_MTU itself as a value | expand |
Am 25.08.22 um 11:29 schrieb Fiona Ebner: > Currently, VMXNET3_MAX_MTU itself (being 9000) is not considered a > valid value for the MTU, but a guest running ESXi 7.0 might try to > set it and fail the assert [0]. > > In the Linux kernel, dev->max_mtu itself is a valid value for the MTU > and for the vmxnet3 driver it's 9000, so a guest running Linux will > also fail the assert when trying to set an MTU of 9000. > > VMXNET3_MAX_MTU and s->mtu don't seem to be used in relation to buffer > allocations/accesses, so allowing the upper limit itself as a value > should be fine. > > [0]: https://forum.proxmox.com/threads/114011/ > > Fixes: d05dcd94ae ("net: vmxnet3: validate configuration values during activate (CVE-2021-20203)") > Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> > --- > > Feel free to adapt the commit message as you see fit. > > v1 -> v2: > * Add commit message with some rationale. > > hw/net/vmxnet3.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c > index 0b7acf7f89..a2037583bf 100644 > --- a/hw/net/vmxnet3.c > +++ b/hw/net/vmxnet3.c > @@ -1441,7 +1441,7 @@ static void vmxnet3_activate_device(VMXNET3State *s) > vmxnet3_setup_rx_filtering(s); > /* Cache fields from shared memory */ > s->mtu = VMXNET3_READ_DRV_SHARED32(d, s->drv_shmem, devRead.misc.mtu); > - assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu < VMXNET3_MAX_MTU); > + assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu <= VMXNET3_MAX_MTU); > VMW_CFPRN("MTU is %u", s->mtu); > > s->max_rx_frags = Ping
On Wed, Dec 14, 2022 at 5:43 PM Fiona Ebner <f.ebner@proxmox.com> wrote: > > Am 25.08.22 um 11:29 schrieb Fiona Ebner: > > Currently, VMXNET3_MAX_MTU itself (being 9000) is not considered a > > valid value for the MTU, but a guest running ESXi 7.0 might try to > > set it and fail the assert [0]. > > > > In the Linux kernel, dev->max_mtu itself is a valid value for the MTU > > and for the vmxnet3 driver it's 9000, so a guest running Linux will > > also fail the assert when trying to set an MTU of 9000. > > > > VMXNET3_MAX_MTU and s->mtu don't seem to be used in relation to buffer > > allocations/accesses, so allowing the upper limit itself as a value > > should be fine. > > > > [0]: https://forum.proxmox.com/threads/114011/ > > > > Fixes: d05dcd94ae ("net: vmxnet3: validate configuration values during activate (CVE-2021-20203)") > > Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> > > --- > > > > Feel free to adapt the commit message as you see fit. > > > > v1 -> v2: > > * Add commit message with some rationale. > > > > hw/net/vmxnet3.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c > > index 0b7acf7f89..a2037583bf 100644 > > --- a/hw/net/vmxnet3.c > > +++ b/hw/net/vmxnet3.c > > @@ -1441,7 +1441,7 @@ static void vmxnet3_activate_device(VMXNET3State *s) > > vmxnet3_setup_rx_filtering(s); > > /* Cache fields from shared memory */ > > s->mtu = VMXNET3_READ_DRV_SHARED32(d, s->drv_shmem, devRead.misc.mtu); > > - assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu < VMXNET3_MAX_MTU); > > + assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu <= VMXNET3_MAX_MTU); > > VMW_CFPRN("MTU is %u", s->mtu); > > > > s->max_rx_frags = > > Ping I've queued this patch. Thanks >
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c index 0b7acf7f89..a2037583bf 100644 --- a/hw/net/vmxnet3.c +++ b/hw/net/vmxnet3.c @@ -1441,7 +1441,7 @@ static void vmxnet3_activate_device(VMXNET3State *s) vmxnet3_setup_rx_filtering(s); /* Cache fields from shared memory */ s->mtu = VMXNET3_READ_DRV_SHARED32(d, s->drv_shmem, devRead.misc.mtu); - assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu < VMXNET3_MAX_MTU); + assert(VMXNET3_MIN_MTU <= s->mtu && s->mtu <= VMXNET3_MAX_MTU); VMW_CFPRN("MTU is %u", s->mtu); s->max_rx_frags =
Currently, VMXNET3_MAX_MTU itself (being 9000) is not considered a valid value for the MTU, but a guest running ESXi 7.0 might try to set it and fail the assert [0]. In the Linux kernel, dev->max_mtu itself is a valid value for the MTU and for the vmxnet3 driver it's 9000, so a guest running Linux will also fail the assert when trying to set an MTU of 9000. VMXNET3_MAX_MTU and s->mtu don't seem to be used in relation to buffer allocations/accesses, so allowing the upper limit itself as a value should be fine. [0]: https://forum.proxmox.com/threads/114011/ Fixes: d05dcd94ae ("net: vmxnet3: validate configuration values during activate (CVE-2021-20203)") Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> --- Feel free to adapt the commit message as you see fit. v1 -> v2: * Add commit message with some rationale. hw/net/vmxnet3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)