* Potential bug in gpiolib-cdev.c in v1 notification about line info changes
@ 2021-06-15 18:57 Gabriel Knezek
2021-06-16 10:44 ` Kent Gibson
0 siblings, 1 reply; 4+ messages in thread
From: Gabriel Knezek @ 2021-06-15 18:57 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski; +Cc: linux-gpio@vger.kernel.org
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.
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.
Thanks!
-Gabe Knezek
gabeknez@microsoft.com
Azure Sphere Team, Microsoft Corporation
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Potential bug in gpiolib-cdev.c in v1 notification about line info changes
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
2021-06-16 21:24 ` [EXTERNAL] " Gabriel Knezek
0 siblings, 1 reply; 4+ messages in thread
From: Kent Gibson @ 2021-06-16 10:44 UTC (permalink / raw)
To: Gabriel Knezek
Cc: Linus Walleij, Bartosz Golaszewski, linux-gpio@vger.kernel.org
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.
^ permalink raw reply [flat|nested] 4+ messages in thread* RE: [EXTERNAL] Re: Potential bug in gpiolib-cdev.c in v1 notification about line info changes
2021-06-16 10:44 ` Kent Gibson
@ 2021-06-16 21:24 ` Gabriel Knezek
2021-06-17 0:56 ` Kent Gibson
0 siblings, 1 reply; 4+ messages in thread
From: Gabriel Knezek @ 2021-06-16 21:24 UTC (permalink / raw)
To: Kent Gibson
Cc: Linus Walleij, Bartosz Golaszewski, linux-gpio@vger.kernel.org
>
> 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.
Sounds good. I'll send out the patch shortly.
Do you think I should CC: security@kernel.org on the patch?
Thanks.
-Gabe
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [EXTERNAL] Re: Potential bug in gpiolib-cdev.c in v1 notification about line info changes
2021-06-16 21:24 ` [EXTERNAL] " Gabriel Knezek
@ 2021-06-17 0:56 ` Kent Gibson
0 siblings, 0 replies; 4+ messages in thread
From: Kent Gibson @ 2021-06-17 0:56 UTC (permalink / raw)
To: Gabriel Knezek
Cc: Linus Walleij, Bartosz Golaszewski, linux-gpio@vger.kernel.org
On Wed, Jun 16, 2021 at 09:24:01PM +0000, Gabriel Knezek wrote:
> >
> > 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.
>
> Sounds good. I'll send out the patch shortly.
> Do you think I should CC: security@kernel.org on the patch?
>
Not totally clear on the procedure myself, and give this is a potential
security issue, you probably should've gone there first, or mailed the
maintainers privately rather than going straight to the list?
For that matter, I probably should've replied privately rather than
confirming the bug on the list. But that horse has bolted.
I'd expect the maintainers to promptly direct the patch to the appropriate
channels, though forwarding a copy to security@kernel.org probably
couldn't hurt.
Thanks again for spotting this one - I'm still kicking myself for
missing it.
Cheers,
Kent.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-06-17 0:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2021-06-16 21:24 ` [EXTERNAL] " Gabriel Knezek
2021-06-17 0:56 ` Kent Gibson
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.