drivers/hv/vmbus_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
To work around a misbehavior of the compiler's ability to see into
composite flexible array structs (as detailed in the coming memcpy()
hardening series[1]), split the memcpy() of the header and the payload
so no false positive run-time overflow warning will be generated. As it
turns out, this appears to actually reduce the text size:
$ size drivers/hv/vmbus_drv.o.before drivers/hv/vmbus_drv.o
text data bss dec hex filename
22968 5239 232 28439 6f17 drivers/hv/vmbus_drv.o.before
23032 5239 232 28503 6f57 drivers/hv/vmbus_drv.o
[1] https://lore.kernel.org/linux-hardening/20220901065914.1417829-2-keescook@chromium.org/
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: linux-hyperv@vger.kernel.org
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reported-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
drivers/hv/vmbus_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 23c680d1a0f5..9b111a8262e3 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1131,7 +1131,8 @@ void vmbus_on_msg_dpc(unsigned long data)
return;
INIT_WORK(&ctx->work, vmbus_onmessage_work);
- memcpy(&ctx->msg, &msg_copy, sizeof(msg->header) + payload_size);
+ ctx->msg.header = msg_copy.header;
+ memcpy(&ctx->msg.payload, msg_copy.u.payload, payload_size);
/*
* The host can generate a rescind message while we
--
2.34.1
On Fri, Sep 23, 2022 at 08:07:41PM -0700, Kees Cook wrote: > To work around a misbehavior of the compiler's ability to see into > composite flexible array structs (as detailed in the coming memcpy() > hardening series[1]), split the memcpy() of the header and the payload > so no false positive run-time overflow warning will be generated. As it > turns out, this appears to actually reduce the text size: > > $ size drivers/hv/vmbus_drv.o.before drivers/hv/vmbus_drv.o > text data bss dec hex filename > 22968 5239 232 28439 6f17 drivers/hv/vmbus_drv.o.before > 23032 5239 232 28503 6f57 drivers/hv/vmbus_drv.o > > [1] https://lore.kernel.org/linux-hardening/20220901065914.1417829-2-keescook@chromium.org/ > > Cc: "K. Y. Srinivasan" <kys@microsoft.com> > Cc: Haiyang Zhang <haiyangz@microsoft.com> > Cc: Stephen Hemminger <sthemmin@microsoft.com> > Cc: Wei Liu <wei.liu@kernel.org> > Cc: Dexuan Cui <decui@microsoft.com> > Cc: linux-hyperv@vger.kernel.org > Reported-by: Nathan Chancellor <nathan@kernel.org> > Reported-by: "Gustavo A. R. Silva" <gustavoars@kernel.org> > Signed-off-by: Kees Cook <keescook@chromium.org> I was waiting for another -next update to test this in WSL2; now that said update has happened, I can see that this does resolve the runtime warning that I saw. Tested-by: Nathan Chancellor <nathan@kernel.org> > --- > drivers/hv/vmbus_drv.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c > index 23c680d1a0f5..9b111a8262e3 100644 > --- a/drivers/hv/vmbus_drv.c > +++ b/drivers/hv/vmbus_drv.c > @@ -1131,7 +1131,8 @@ void vmbus_on_msg_dpc(unsigned long data) > return; > > INIT_WORK(&ctx->work, vmbus_onmessage_work); > - memcpy(&ctx->msg, &msg_copy, sizeof(msg->header) + payload_size); > + ctx->msg.header = msg_copy.header; > + memcpy(&ctx->msg.payload, msg_copy.u.payload, payload_size); > > /* > * The host can generate a rescind message while we > -- > 2.34.1 > >
On Fri, Sep 23, 2022 at 08:07:41PM -0700, Kees Cook wrote: > To work around a misbehavior of the compiler's ability to see into > composite flexible array structs (as detailed in the coming memcpy() > hardening series[1]), split the memcpy() of the header and the payload > so no false positive run-time overflow warning will be generated. As it > turns out, this appears to actually reduce the text size: > > $ size drivers/hv/vmbus_drv.o.before drivers/hv/vmbus_drv.o > text data bss dec hex filename > 22968 5239 232 28439 6f17 drivers/hv/vmbus_drv.o.before > 23032 5239 232 28503 6f57 drivers/hv/vmbus_drv.o > > [1] https://lore.kernel.org/linux-hardening/20220901065914.1417829-2-keescook@chromium.org/ > > Cc: "K. Y. Srinivasan" <kys@microsoft.com> > Cc: Haiyang Zhang <haiyangz@microsoft.com> > Cc: Stephen Hemminger <sthemmin@microsoft.com> > Cc: Wei Liu <wei.liu@kernel.org> > Cc: Dexuan Cui <decui@microsoft.com> > Cc: linux-hyperv@vger.kernel.org > Reported-by: Nathan Chancellor <nathan@kernel.org> > Reported-by: "Gustavo A. R. Silva" <gustavoars@kernel.org> > Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Thanks! -- Gustavo > --- > drivers/hv/vmbus_drv.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c > index 23c680d1a0f5..9b111a8262e3 100644 > --- a/drivers/hv/vmbus_drv.c > +++ b/drivers/hv/vmbus_drv.c > @@ -1131,7 +1131,8 @@ void vmbus_on_msg_dpc(unsigned long data) > return; > > INIT_WORK(&ctx->work, vmbus_onmessage_work); > - memcpy(&ctx->msg, &msg_copy, sizeof(msg->header) + payload_size); > + ctx->msg.header = msg_copy.header; > + memcpy(&ctx->msg.payload, msg_copy.u.payload, payload_size); > > /* > * The host can generate a rescind message while we > -- > 2.34.1 >
On Fri, Sep 23, 2022 at 10:42:38PM -0500, Gustavo A. R. Silva wrote:
> On Fri, Sep 23, 2022 at 08:07:41PM -0700, Kees Cook wrote:
> > To work around a misbehavior of the compiler's ability to see into
> > composite flexible array structs (as detailed in the coming memcpy()
> > hardening series[1]), split the memcpy() of the header and the payload
> > so no false positive run-time overflow warning will be generated. As it
> > turns out, this appears to actually reduce the text size:
Er, actually, I can't read/math. ;) It _does_ grow the text size. (That's
2_3_ not 22 at the start of the text size...) On examination, it appears
to unroll the already inlined memcpy further.
> >
> > $ size drivers/hv/vmbus_drv.o.before drivers/hv/vmbus_drv.o
> > text data bss dec hex filename
> > 22968 5239 232 28439 6f17 drivers/hv/vmbus_drv.o.before
> > 23032 5239 232 28503 6f57 drivers/hv/vmbus_drv.o
^
-Kees
--
Kees Cook
Hi Kees On Fri, Sep 23, 2022 at 09:22:55PM -0700, Kees Cook wrote: > On Fri, Sep 23, 2022 at 10:42:38PM -0500, Gustavo A. R. Silva wrote: > > On Fri, Sep 23, 2022 at 08:07:41PM -0700, Kees Cook wrote: > > > To work around a misbehavior of the compiler's ability to see into > > > composite flexible array structs (as detailed in the coming memcpy() > > > hardening series[1]), split the memcpy() of the header and the payload > > > so no false positive run-time overflow warning will be generated. As it > > > turns out, this appears to actually reduce the text size: > > Er, actually, I can't read/math. ;) It _does_ grow the text size. (That's > 2_3_ not 22 at the start of the text size...) On examination, it appears > to unroll the already inlined memcpy further. Can you provide an updated commit message? No need to resend. Thanks, Wei. > > > > > > > $ size drivers/hv/vmbus_drv.o.before drivers/hv/vmbus_drv.o > > > text data bss dec hex filename > > > 22968 5239 232 28439 6f17 drivers/hv/vmbus_drv.o.before > > > 23032 5239 232 28503 6f57 drivers/hv/vmbus_drv.o > ^ > > -Kees > > -- > Kees Cook
On Sat, Sep 24, 2022 at 10:34:12AM +0000, Wei Liu wrote: > Hi Kees > > On Fri, Sep 23, 2022 at 09:22:55PM -0700, Kees Cook wrote: > > On Fri, Sep 23, 2022 at 10:42:38PM -0500, Gustavo A. R. Silva wrote: > > > On Fri, Sep 23, 2022 at 08:07:41PM -0700, Kees Cook wrote: > > > > To work around a misbehavior of the compiler's ability to see into > > > > composite flexible array structs (as detailed in the coming memcpy() > > > > hardening series[1]), split the memcpy() of the header and the payload > > > > so no false positive run-time overflow warning will be generated. As it > > > > turns out, this appears to actually reduce the text size: > > > > Er, actually, I can't read/math. ;) It _does_ grow the text size. (That's > > 2_3_ not 22 at the start of the text size...) On examination, it appears > > to unroll the already inlined memcpy further. > > Can you provide an updated commit message? No need to resend. Since I got more testing from Nathan (and the original warning message), I figured a full v2 respin would easier. Now sent. :) Thanks! -Kees -- Kees Cook
© 2016 - 2026 Red Hat, Inc.