int[1]' [-Warray-bounds]
119 | unsigned long val = *addr & GENMASK(size - 1, 0);
| ^
drivers/iommu/intel/iommu.c:2115:18: note: while referencing 'max_pde'
2115 | int pds, max_pde;
| ^~~
Signed-off-by
On Tue, Sep 28, 2021 at 05:22:29PM -0500, Gustavo A. R. Silva wrote:
> Use 2-factor argument form kvcalloc() instead of kvzalloc().
>
> Link: https://github.com/KSPP/linux/issues/162
> Signed-off-by: Gustavo A. R. Silva
Looks right.
Reviewed-by: Kees Cook
-
erg Roedel
Cc: Will Deacon
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Kees Cook
---
drivers/iommu/amd/init.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index bdcf167b4afe..70506d6175e9 100644
--- a/driv
On Wed, Oct 28, 2020 at 10:13:52PM +0100, Thomas Gleixner wrote:
> On Wed, Oct 28 2020 at 13:49, Kees Cook wrote:
> > On Sat, Oct 24, 2020 at 10:35:15PM +0100, David Woodhouse wrote:
> >> + memset(&msg, 0, sizeof(*msg);
> >
> > This should be:
>
f(*msg);
This should be:
+ memset(msg, 0, sizeof(*msg);
https://groups.google.com/g/clang-built-linux/c/N-DfCPz3alg
> + msg->address_hi = X86_MSI_BASE_ADDRESS_HIGH;
> + msg->arch_addr_lo.base_address = X86_MSI_BASE_AD
On Wed, Oct 30, 2019 at 07:09:21PM +0100, Christoph Hellwig wrote:
> On Wed, Oct 30, 2019 at 10:18:49AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Oct 29, 2019 at 02:34:22PM -0700, Kees Cook wrote:
> > > As we've seen from USB and other areas[1], we need to always do runti
.
[1] https://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb
-Kees
Kees Cook (2):
dma-mapping: Add vmap checks to dma_map_single()
usb: core: Remove redundant vmap checks
drivers/usb/core/hcd.c | 8 +---
include/linux/dma-mapping.h | 6 ++
2 files changed, 7 inser
https://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb
Suggested-by: Laura Abbott
Signed-off-by: Kees Cook
---
include/linux/dma-mapping.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 4a1c4fca475a..54de3c4
Now that the vmap area checks are being performed in the DMA
infrastructure directly, there is no need to repeat them in USB.
Signed-off-by: Kees Cook
---
drivers/usb/core/hcd.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core
Now that the vmap area checks are being performed in the DMA
infrastructure directly, there is no need to repeat them in USB.
Signed-off-by: Kees Cook
---
drivers/usb/core/hcd.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core
https://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb
Suggested-by: Laura Abbott
Signed-off-by: Kees Cook
---
include/linux/dma-mapping.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 4a1c4fca475a..ff4e91c
/lkml/201910021341.7819A660@keescook
Kees Cook (2):
dma-mapping: Add vmap checks to dma_map_single()
usb: core: Remove redundant vmap checks
drivers/usb/core/hcd.c | 8 +---
include/linux/dma-mapping.h | 6 ++
2 files changed, 7 insertions(+), 7 deletions(-)
--
2.17.1
ff-by: Kees Cook
---
v2: Only add is_vmalloc_addr()
v1: https://lore.kernel.org/lkml/201910021341.7819A660@keescook
---
drivers/usb/core/hcd.c | 8 +---
include/linux/dma-mapping.h | 7 +++
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb
On Fri, Oct 04, 2019 at 07:50:54PM +0100, Robin Murphy wrote:
> On 03/10/2019 22:38, Kees Cook wrote:
> > What do you think about the object_is_on_stack() check? That does a
> > dereference through "current" to find the stack bounds...
>
> I guess it depends what
On Thu, Oct 03, 2019 at 10:42:45AM +0100, Robin Murphy wrote:
> On 03/10/2019 00:58, Kees Cook wrote:
> > On Wed, Oct 02, 2019 at 10:15:43PM +0100, Robin Murphy wrote:
> > > Hi Kees,
> > >
> > > On 2019-10-02 9:46 pm, Kees Cook wrote:
> > > > As
On Wed, Oct 02, 2019 at 04:58:39PM -0700, Kees Cook wrote:
> In the USB case, it'll actually refuse to do the operation. Should
> dma_map_single() similarly fail? I could push these checks down into
> dma_map_single(), which would be a no-change on behavior for USB and
> gain
On Wed, Oct 02, 2019 at 10:15:43PM +0100, Robin Murphy wrote:
> Hi Kees,
>
> On 2019-10-02 9:46 pm, Kees Cook wrote:
> > As we've seen from USB and other areas, we need to always do runtime
> > checks for DMA operating on memory regions that might be remapped. This
>
seen in a few recent reports).
Suggested-by: Laura Abbott
Signed-off-by: Kees Cook
---
include/linux/dma-debug.h | 8
include/linux/dma-mapping.h | 8 +++-
kernel/dma/debug.c | 16
3 files changed, 7 insertions(+), 25 deletions(-)
diff --git a/include/
On Thu, Apr 18, 2019 at 7:35 AM Khalid Aziz wrote:
>
> On 4/17/19 11:41 PM, Kees Cook wrote:
> > On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote:
> >> I don't think this type of NX goof was ever the argument for XPFO.
> >> The main argument I'v
buffers, etc.
My understanding is that it's much easier to feel out the linear
mapping address than for the others. But yes, all of those same attack
primitives are possible in other memory areas (though most are NX),
and plenty of exploits have done such things.
--
Kees Cook
___
This removes needless use of '%p', and refactors the printk calls to
use pr_*() helpers instead.
Signed-off-by: Kees Cook
---
kernel/dma/swiotlb.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiot
ot;
Cc: x...@kernel.org
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Kees Cook
---
arch/x86/kernel/pci-calgary_64.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
index 5286a4a92cf7..35c461f21815 10
On Mon, Dec 5, 2016 at 2:47 PM, David Woodhouse wrote:
> On Mon, 2016-12-05 at 14:18 -0800, Kees Cook wrote:
>> Hm, I have no idea. :) What would I look for in the BIOS?
>
> For a start, what is the actual failure mode?
Based on initial testing (not that I've spent tons of t
On Mon, Dec 5, 2016 at 2:07 PM, David Woodhouse wrote:
> On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote:
>> This blacklists the Q35 integrated graphics so IOMMU can be otherwise
>> enabled. Without this, a Q35 system can only enable IOMMU when booting
>> with "intel_
Expansion ROM at [disabled]
Capabilities:
Kernel driver in use: i915
Kernel modules: i915
Signed-off-by: Kees Cook
---
drivers/iommu/intel-iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.
This makes sure it won't be possible to accidentally leak format
strings into iommu device names. Current name allocations are safe,
but this makes the "%s" explicit.
Signed-off-by: Kees Cook
---
drivers/iommu/dmar.c| 2 +-
drivers/iommu/intel-iommu.c | 2 +-
2 f
26 matches
Mail list logo