From: Kent Gibson <warthog618@gmail.com>
To: Gabriel Knezek <gabeknez@microsoft.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: Potential bug in gpiolib-cdev.c in v1 notification about line info changes
Date: Wed, 16 Jun 2021 18:44:42 +0800 [thread overview]
Message-ID: <20210616104442.GA160816@sol> (raw)
In-Reply-To: <SN4PR2101MB0734B4BE5D7750A5CD43C3ACDA309@SN4PR2101MB0734.namprd21.prod.outlook.com>
On Tue, Jun 15, 2021 at 06:57:03PM +0000, Gabriel Knezek wrote:
> Hello GPIO maintainers,
>
> While upgrading our system from the 5.4 to 5.10 kernel release, we noticed this potential defect in the gpiolib-cdev.c file: https://github.com/torvalds/linux/blob/master/drivers/gpio/gpiolib-cdev.c#L2255
>
> In the lineinfo_watch_read routine,
>
> } else {
> struct gpioline_info_changed event_v1;
> gpio_v2_line_info_changed_to_v1(&event, &event_v1);
> if (copy_to_user(buf + bytes_read, &event_v1,
> event_size))
> return -EFAULT;
> }
>
> if userspace requests a GPIO v1 line info changed event, the kernel populates and returns the event_v1 structure. That structure (https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5c4c173d3639d4772966/include/uapi/linux/gpio.h#L367) contains 5 words of padding at the end of the structure that do not appear to be initialized in the gpio_v2_line_info_change_to_v1 routine (nor its subordinate routines):
>
> struct gpioline_info_changed {
> struct gpioline_info info;
> __u64 timestamp;
> __u32 event_type;
> __u32 padding[5]; /* for future use */
> };
>
> It appears that this could be a potential kernel information leak to userspace, and could be fixed by zeroing out the padding field before copying the structure to userspace.
>
Looks like a bug to me too - well spotted :(.
> We wanted to get your thoughts on if you feel this is actually a bug, or if we overlooked something.
> We're proposing to fix this issue by memsetting the entire structure to zero before calling the conversion routine; if you agree that that's a valid approach, I'm happy to submit an official patch.
>
Go for it.
I'd zero the padding in the conversion routine myself, but zeroing the
whole struct in the same routine as the copy_to_user(), as you suggest,
would more clearly demonstrate that it isn't leaking stack.
Cheers,
Kent.
next prev parent reply other threads:[~2021-06-16 10:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-15 18:57 Potential bug in gpiolib-cdev.c in v1 notification about line info changes Gabriel Knezek
2021-06-16 10:44 ` Kent Gibson [this message]
2021-06-16 21:24 ` [EXTERNAL] " Gabriel Knezek
2021-06-17 0:56 ` Kent Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210616104442.GA160816@sol \
--to=warthog618@gmail.com \
--cc=bgolaszewski@baylibre.com \
--cc=gabeknez@microsoft.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.