lkml.org 
[lkml]   [2024]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CVE-2023-52466: PCI: Avoid potential out-of-bounds read in pci_dev_for_each_resource()
On Tue, 27 Feb 2024, Greg Kroah-Hartman wrote:

> > 09cc90063240 ("PCI: Introduce pci_dev_for_each_resource()") added
> > pci_dev_for_each_resource(), which expands to:
> >
> > for (...; res = (&(dev)->resource[(bar)]), bar < PCI_NUM_RESOURCES; ...)
> >
> > We compute "res" before the bounds-check of "bar", so the pointer may
> > be out-of-bounds, but the body of the pci_dev_for_each_resource() loop
> > is never executed with that out-of-bounds value.
> >
> > So I don't think this is a security issue, no matter how
> > pci_dev_for_each_resource() is used, unless the mere presence of an
> > invalid address in a register is an issue.
>
> Ah, yeah, now I remember, stuff like this was fixed up in other loops as
> just reading off into the wild can be a speculation issue and so we had
> to fix up a bunch of places in the kernel where we did have "invalid
> data" in a register. The code didn't use that, but the processor would
> fetch from there, and boom, speculation mess. There's a whole research
> paper published on this type of thing somewhere...

Greg, could you please elaborate on this?

Where in this whole construct do you see a potential for *_uncached_* (!)
memory access that'd cause CPU to speculate into the wild? I just don't
see it.

Thanks,

--
Jiri Kosina
SUSE Labs


\
 
 \ /
  Last update: 2024-02-28 10:20    [W:2.063 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site