| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <202205040730.161645EC@keescook>
Date: Wed, 4 May 2022 08:08:26 -0700
From: Kees Cook <keescook@...omium.org>
To: Kalle Valo <kvalo@...nel.org>
Cc: "Gustavo A . R . Silva" <gustavoars@...nel.org>,
Loic Poulain <loic.poulain@...aro.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, wcn36xx@...ts.infradead.org,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
Alexei Starovoitov <ast@...nel.org>,
alsa-devel@...a-project.org, Al Viro <viro@...iv.linux.org.uk>,
Andrew Gabbasov <andrew_gabbasov@...tor.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Andy Gross <agross@...nel.org>,
Andy Lavr <andy.lavr@...il.com>,
Arend van Spriel <aspriel@...il.com>,
Baowen Zheng <baowen.zheng@...igine.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Bradley Grove <linuxdrivers@...otech.com>,
brcm80211-dev-list.pdl@...adcom.com,
Christian Brauner <brauner@...nel.org>,
Christian Göttsche <cgzones@...glemail.com>,
Christian Lamparter <chunkeey@...glemail.com>,
Chris Zankel <chris@...kel.net>,
Cong Wang <cong.wang@...edance.com>,
Daniel Axtens <dja@...ens.net>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Dan Williams <dan.j.williams@...el.com>,
David Gow <davidgow@...gle.com>,
David Howells <dhowells@...hat.com>,
Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>,
devicetree@...r.kernel.org, Dexuan Cui <decui@...rosoft.com>,
Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
Eli Cohen <elic@...dia.com>,
Eric Paris <eparis@...isplace.org>,
Eugeniu Rosca <erosca@...adit-jv.com>,
Felipe Balbi <balbi@...nel.org>,
Francis Laniel <laniel_francis@...vacyrequired.com>,
Frank Rowand <frowand.list@...il.com>,
Franky Lin <franky.lin@...adcom.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Gregory Greenman <gregory.greenman@...el.com>,
Guenter Roeck <linux@...ck-us.net>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Hante Meuleman <hante.meuleman@...adcom.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Hulk Robot <hulkci@...wei.com>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
James Morris <jmorris@...ei.org>,
Jarkko Sakkinen <jarkko@...nel.org>,
Jaroslav Kysela <perex@...ex.cz>,
Jason Gunthorpe <jgg@...pe.ca>, Jens Axboe <axboe@...nel.dk>,
Johan Hedberg <johan.hedberg@...il.com>,
Johannes Berg <johannes.berg@...el.com>,
Johannes Berg <johannes@...solutions.net>,
John Keeping <john@...anate.com>,
Juergen Gross <jgross@...e.com>,
Keith Packard <keithp@...thp.com>, keyrings@...r.kernel.org,
kunit-dev@...glegroups.com,
Kuniyuki Iwashima <kuniyu@...zon.co.jp>,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Lars-Peter Clausen <lars@...afoo.de>,
Lee Jones <lee.jones@...aro.org>,
Leon Romanovsky <leon@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
linux1394-devel@...ts.sourceforge.net,
linux-afs@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, linux-bluetooth@...r.kernel.org,
linux-hardening@...r.kernel.org, linux-hyperv@...r.kernel.org,
linux-integrity@...r.kernel.org, linux-rdma@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-security-module@...r.kernel.org,
linux-usb@...r.kernel.org, linux-xtensa@...ux-xtensa.org,
llvm@...ts.linux.dev, Louis Peens <louis.peens@...igine.com>,
Luca Coelho <luciano.coelho@...el.com>,
Luiz Augusto von Dentz <luiz.dentz@...il.com>,
Marcel Holtmann <marcel@...tmann.org>,
Mark Brown <broonie@...nel.org>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Max Filippov <jcmvbkbc@...il.com>,
Mimi Zohar <zohar@...ux.ibm.com>,
Muchun Song <songmuchun@...edance.com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nuno Sá <nuno.sa@...log.com>,
Paul Moore <paul@...l-moore.com>,
Rich Felker <dalias@...ifal.cx>,
Rob Herring <robh+dt@...nel.org>,
Russell King <linux@...linux.org.uk>, selinux@...r.kernel.org,
"Serge E. Hallyn" <serge@...lyn.com>,
SHA-cyfmac-dev-list@...ineon.com,
Simon Horman <simon.horman@...igine.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Stefan Richter <stefanr@...6.in-berlin.de>,
Steffen Klassert <steffen.klassert@...unet.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Stephen Smalley <stephen.smalley.work@...il.com>,
Tadeusz Struk <tadeusz.struk@...aro.org>,
Takashi Iwai <tiwai@...e.com>, Tom Rix <trix@...hat.com>,
Udipto Goswami <quic_ugoswami@...cinc.com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Wei Liu <wei.liu@...nel.org>, xen-devel@...ts.xenproject.org,
Xiu Jianfeng <xiujianfeng@...wei.com>,
Yang Yingliang <yangyingliang@...wei.com>
Subject: Re: [PATCH 10/32] wcn36xx: Use mem_to_flex_dup() with struct
wcn36xx_hal_ind_msg
On Wed, May 04, 2022 at 08:42:46AM +0300, Kalle Valo wrote:
> Kees Cook <keescook@...omium.org> writes:
>
> > As part of the work to perform bounds checking on all memcpy() uses,
> > replace the open-coded a deserialization of bytes out of memory into a
> > trailing flexible array by using a flex_array.h helper to perform the
> > allocation, bounds checking, and copying.
> >
> > Cc: Loic Poulain <loic.poulain@...aro.org>
> > Cc: Kalle Valo <kvalo@...nel.org>
> > Cc: "David S. Miller" <davem@...emloft.net>
> > Cc: Eric Dumazet <edumazet@...gle.com>
> > Cc: Jakub Kicinski <kuba@...nel.org>
> > Cc: Paolo Abeni <pabeni@...hat.com>
> > Cc: wcn36xx@...ts.infradead.org
> > Cc: linux-wireless@...r.kernel.org
> > Cc: netdev@...r.kernel.org
> > Signed-off-by: Kees Cook <keescook@...omium.org>
>
> [...]
>
> > --- a/drivers/net/wireless/ath/wcn36xx/smd.h
> > +++ b/drivers/net/wireless/ath/wcn36xx/smd.h
> > @@ -46,8 +46,8 @@ struct wcn36xx_fw_msg_status_rsp {
> >
> > struct wcn36xx_hal_ind_msg {
> > struct list_head list;
> > - size_t msg_len;
> > - u8 msg[];
> > + DECLARE_FLEX_ARRAY_ELEMENTS_COUNT(size_t, msg_len);
> > + DECLARE_FLEX_ARRAY_ELEMENTS(u8, msg);
>
> This affects readability quite a lot and tbh I don't like it. Isn't
> there any simpler way to solve this?
Similar to how I plumbed member names into __mem_to_flex(), I could do
the same for __mem_to_flex_dup(). That way if the struct member aliases
(DECLARE_FLEX...) aren't added, the longer form of the helper could
be used. Instead of:
if (mem_to_flex_dup(&msg_ind, buf, len, GFP_ATOMIC)) {
it would be:
if (__mem_to_flex_dup(&msg_ind, /* self */, msg,
msg_len, buf, len, GFP_ATOMIC)) {
This was how I'd written the helpers in an earlier version, but it
seemed much cleaner to avoid repeating structure layout details at each
call site.
I couldn't find any other way to encode the needed information. It'd be
wonderful if C would let us do:
struct wcn36xx_hal_ind_msg {
struct list_head list;
size_t msg_len;
u8 msg[msg_len];
}
And provide some kind of interrogation:
__builtin_flex_array_member(msg_ind) -> msg_ind->msg
__builtin_flex_array_count(msg_ind) -> msg_ind->msg_len
My hope would be to actually use the member aliases to teach things like
-fsanitize=array-bounds about flexible arrays. If it encounters a
structure with the aliases, it could add the instrumentation to do the
bounds checking of things like:
msg_ind->msg[42]; /* check that 42 is < msg_ind->msg_len */
I also wish I could find a way to make the proposed macros "forward
portable" into proposed C syntax above, but this eluded me as well.
For example:
struct wcn36xx_hal_ind_msg {
size_t msg_len;
struct list_head list;
BOUNDED_FLEX_ARRAY(u8, msg, msg_len);
}
#ifdef CC_HAS_DYNAMIC_ARRAY_LEN
# define BOUNDED_FLEX_ARRAY(type, name, bounds) type name[bounds]
#else
# define BOUNDED_FLEX_ARRAY(type, name, bounds) \
magic_alias_of msg_len __flex_array_elements_count; \
union { \
type name[]; \
type __flex_array_elements[]; \
}
#endif
But I couldn't sort out the "magic_alias_of" syntax that wouldn't force
structures into having the count member immediately before the flex
array, which would impose more limitations on where this could be
used...
Anyway, I'm open to ideas on how to improve this!
-Kees
--
Kees Cook
Powered by blists - more mailing lists