On Thu, Sep 04, 2025 at 10:34:04AM +0300, Jani Nikula wrote:
> On Wed, 03 Sep 2025, Kees Cook wrote:
> > On Fri, Aug 29, 2025 at 08:46:01PM +0300, Jani Nikula wrote:
> >> Move the range_overflows() and range_end_overflows() along with the _t
> >> variants over fro
On Fri, Aug 29, 2025 at 08:46:01PM +0300, Jani Nikula wrote:
> Move the range_overflows() and range_end_overflows() along with the _t
> variants over from drm/i915 and drm/buddy to overflow.h.
>
> Cc: Kees Cook
> Cc: Gustavo A. R. Silva
> Cc: linux-harden...@vger.kernel.o
abilities. Putting a
filename into the tree exposes the address to anything that can get a
file listing, and DAC access control isn't granular enough.
(Thank you again for the fix patch I saw in the other thread!)
--
Kees Cook
userspace like this. If you absolutely must,
use %p, but never %px. This is a kernel address leak:
https://docs.kernel.org/process/deprecated.html#p-format-specifier
"helpful for debugging" is not a sufficiently good reason; and "only
accessible by root" has nothing to do with kernel address integrity.
Those kinds of things are (roughly) managed by various capabilities,
not DAC uid==0.
--
Kees Cook
Lorenzo Stoakes
>---
> fs/backing-file.c | 2 +-
> fs/binfmt_elf.c | 4 ++--
> fs/binfmt_elf_fdpic.c | 2 +-
Thanks for the refactoring!
Acked-by: Kees Cook
--
Kees Cook
On Mon, Jun 02, 2025 at 04:10:21PM +0300, Jani Nikula wrote:
> On Fri, 30 May 2025, Kees Cook wrote:
> > On Fri, May 30, 2025 at 10:44:31AM +0300, Jani Nikula wrote:
> >>
> >> Hi Kees -
> >>
> >> drivers/gpu/drm/i915/i915_utils.h has a handful of he
ike range_overflows() is not end-inclusive, but
range_overflows_end() is? And the _t variants are forcing explicit
types (like max_t, but unlike struct_size_t).
--
Kees Cook
On Mon, Apr 28, 2025 at 02:40:16PM +0300, Jani Nikula wrote:
> On Fri, 25 Apr 2025, Kees Cook wrote:
> > In preparation for making the kmalloc family of allocators type aware,
> > we need to make sure that the returned type from the allocation matches
> > the type of the va
On Mon, Apr 28, 2025 at 01:09:46PM +0100, Tvrtko Ursulin wrote:
>
> On 26/04/2025 07:13, Kees Cook wrote:
> > In preparation for making the kmalloc family of allocators type aware,
> > we need to make sure that the returned type from the allocation matches
> > the ty
ype.)
The assigned type is "struct i915_wa *". The returned type, while
technically matching, will be const qualified. As there is no general
way to remove const qualifiers, adjust the allocation type to match
the assignment.
Signed-off-by: Kees Cook
---
Cc: Jani Nikula
Cc: Joonas Lahtinen
On Sun, Mar 23, 2025 at 12:42:41PM +, Damian Tometzki wrote:
> On Mon, 10. Mar 15:23, Kees Cook wrote:
> > When a character array without a terminating NUL character has a static
> > initializer, GCC 15's -Wunterminated-string-initialization will only
> > warn if the
desktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i915/gvt/opregion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/opregion.c
b/drivers/gpu/drm/i915/gvt/opregion.c
index 509f9cca
afang Shao
Looks good to me; thanks!
Acked-by: Kees Cook
--
Kees Cook
builds faster?
> 7 files changed, 97 insertions(+), 84 deletions(-)
It makes the code larger too. I don't see what the benefit is, and given how
much time has been spent making sure the existing stuff works correctly, I feel
like we should have a clear benefit to replacing it all.
-Kees
--
Kees Cook
irst user, feel free to
carry it there unless you'd prefer I carry it in my trees?
Reviewed-by: Kees Cook
--
Kees Cook
intuitive or discoverable. Add an explicit mem_is_zero() helper for this
> use case.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Kees Cook
--
Kees Cook
__GFP_NOWARN));
return NULL;
}
So, something is too big in the test?
-Kees
On Sun, Aug 04, 2024 at 04:56:40PM +0800, kernel test robot wrote:
>
> hi, Kees Cook,
>
> as we understand, this commit is not the root cause of WARNING. the WARNING
> just
> changes the fo
lking about
> "crazy" number of relocations which have no practical purpose.
>
> *) Well IGT tests might get upset but they can be easily adjusted.
>
> Signed-off-by: Tvrtko Ursulin
Thanks for fixing this!
Reviewed-by: Kees Cook
--
Kees Cook
const unsigned int nreloc = eb->exec[i].relocation_count;
...
size = nreloc * sizeof(*relocs);
relocs = kvmalloc_array(1, size, GFP_KERNEL);
So something isn't checking the "relocation_count" size that I assume is
coming in from the ioctl?
-Kees
--
Kees Cook
On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote:
>
> > But anyway, there needs to be a general "oops I hit 0"-aware form of
> > get_file(), and it seems like it should just be get_file() itself...
&g
On Fri, May 03, 2024 at 12:41:52AM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 04:21:13PM -0700, Kees Cook wrote:
> > On Fri, May 03, 2024 at 12:12:28AM +0100, Al Viro wrote:
> > > On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote:
> > >
> > >
On Fri, May 03, 2024 at 12:12:28AM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 03:52:21PM -0700, Kees Cook wrote:
>
> > As for semantics, what do you mean? Detecting dec-below-zero means we
> > catch underflow, and detected inc-from-zero means we catch resurrection
> >
On Fri, May 03, 2024 at 12:53:56AM +0200, Jann Horn wrote:
> On Fri, May 3, 2024 at 12:34 AM Kees Cook wrote:
> > If f_count reaches 0, calling get_file() should be a failure. Adjust to
> > use atomic_long_inc_not_zero() and return NULL on failure. In the future
> > get_fi
On Thu, May 02, 2024 at 11:42:50PM +0100, Al Viro wrote:
> On Thu, May 02, 2024 at 03:33:40PM -0700, Kees Cook wrote:
> > Underflow of f_count needs to be more carefully detected than it
> > currently is. The results of get_file() should be checked, but the
> > first step i
Underflow of f_count needs to be more carefully detected than it
currently is. The results of get_file() should be checked, but the
first step is detection. Redefine f_count from atomic_long_t to
refcount_long_t.
Signed-off-by: Kees Cook
---
Cc: Christian Brauner
Cc: Alexander Viro
Cc: Jan
If f_count reaches 0, calling get_file() should be a failure. Adjust to
use atomic_long_inc_not_zero() and return NULL on failure. In the future
get_file() can be annotated with __must_check, though that is not
currently possible.
Signed-off-by: Kees Cook
---
Cc: Christian Brauner
Cc: Alexander
ppear to work well.
Signed-off-by: Kees Cook
---
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Mark Rutland
Cc: Kent Overstreet
Cc: Masahiro Yamada
Cc: Nathan Chancellor
Cc: Nicolas Schier
Cc: linux-kbu...@vger.kernel.org
---
MAINTAINERS| 2 +-
Mak
The correct helper for taking an f_count reference is get_file(). Use it
and check results.
Signed-off-by: Kees Cook
---
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: Andi Shyti
Cc: Lucas De Marchi
Cc: Matt Atwood
Cc
The correct helper for taking an f_count reference is get_file().
Now that it checks for 0 counts, use it and check results.
Signed-off-by: Kees Cook
---
Cc: Zack Rusin
Cc: Broadcom internal kernel review list
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
ago, f_count was switched to atomic_long_t, so to
get proper reference count checking, I've added a refcount_long_t API,
and then converted f_count to refcount_long_t.
Now if there are underflows (or somehow an overflow), we'll see them
reported.
-Kees
Kees Cook (5):
fs: Do not allo
DECLARE_FLEX_ARRAY(struct i915_syncmap *, child);
> + };
This is a new code pattern for me! Trailing arrays of different element
sizes but with a fixed element count. :)
I hope when __counted_by is expanded to take expressions we can add a
literal. :)
Reviewed-by: Kees Cook
--
Kees Cook
vrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-harden...@vger.kernel.org
Link:
https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
[1]
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 2 +-
1 file
On Thu, Oct 05, 2023 at 11:42:38AM +0200, Christian König wrote:
> Am 02.10.23 um 20:22 schrieb Kees Cook:
> > On Mon, Oct 02, 2023 at 08:11:41PM +0200, Christian König wrote:
> > > Am 02.10.23 um 20:08 schrieb Kees Cook:
> > > > On Mon, Oct 02, 2023 at 08:01:57P
On Mon, Oct 02, 2023 at 08:11:41PM +0200, Christian König wrote:
> Am 02.10.23 um 20:08 schrieb Kees Cook:
> > On Mon, Oct 02, 2023 at 08:01:57PM +0200, Christian König wrote:
> > > Am 02.10.23 um 18:53 schrieb Kees Cook:
> > > > On Mon, Oct 02, 2023 at 11:06:
On Mon, Oct 02, 2023 at 08:01:57PM +0200, Christian König wrote:
> Am 02.10.23 um 18:53 schrieb Kees Cook:
> > On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote:
> > > On Mon, Oct 2, 2023 at 5:20 AM Christian König
> > > wrote:
> > > >
On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote:
> On Mon, Oct 2, 2023 at 5:20 AM Christian König
> wrote:
> >
> > Am 29.09.23 um 21:33 schrieb Kees Cook:
> > > On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote:
> > >> This is a batch of pat
On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote:
> This is a batch of patches touching drm for preparing for the coming
> implementation by GCC and Clang of the __counted_by attribute. Flexible
> array members annotated with __counted_by can have their accesses
> bounds-checked
On Mon, Sep 25, 2023 at 08:30:30AM +0200, Christian König wrote:
> Am 22.09.23 um 19:41 schrieb Alex Deucher:
> > On Fri, Sep 22, 2023 at 1:32 PM Kees Cook wrote:
> > > Prepare for the coming implementation by GCC and Clang of the __counted_by
> > > attribute. Flexi
On Mon, Sep 25, 2023 at 12:08:36PM +0200, Andrzej Hajda wrote:
>
>
> On 22.09.2023 19:32, Kees Cook wrote:
> > Prepare for the coming implementation by GCC and Clang of the __counted_by
> > attribute. Flexible array members annotated with __counted_by can have
> > th
functions).
As found with Coccinelle[1], add __counted_by for struct v3d_perfmon.
[1]
https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Emma Anholt
Cc: Melissa Wen
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Kees
functions).
As found with Coccinelle[1], add __counted_by for struct vc4_perfmon.
[1]
https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Emma Anholt
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Kees
...@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 8513b671f871
Cc: Bjorn Andersson
Cc: linux-arm-...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp
: nouv...@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h
b/drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h
index 6ae25d3e7f45
Signed-off-by: Kees Cook
---
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 5db403ee8261..2d1d857f99ae 100644
--- a/drivers/gpu/drm/vmwgfx
d Airlie
Cc: Daniel Vetter
Cc: Xiaojian Du
Cc: Huang Rui
Cc: Kevin Wang
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dr
Cc: John Harrison
Cc: Andi Shyti
Cc: Matthew Brost
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
wking Zhang
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
b/drivers/gpu/drm/amd/amdgp
x27;s initialization
earlier. (These are noted in the individual patches.)
-Kees
[1]
https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Kees Cook (9):
drm/amd/pm: Annotate struct smu10_voltage_dependency_table with
__counted_by
drm/amdgpu/discovery: Annotate s
ppgtt = mock_ppgtt(i915, name);
> if (!ppgtt)
>
> ---
> base-commit: 3669558bdf354cd352be955ef2764cde6a9bf5ec
> change-id:
> 20230914-strncpy-drivers-gpu-drm-i915-gem-selftests-mock_context-c-980c8ecc9142
>
> Best regards,
> --
> Justin Stitt
>
--
Kees Cook
gned-off-by: Azeem Shaikh
Reviewed-by: Kees Cook
--
Kees Cook
ues/271
> Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
--
Kees Cook
ust fetched the remote and don't have this
> > commit in my local repo
>
> That was from
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git (branch
> for-next/kspp) yesterday. It was the top commit in that branch. It is
> still there today (I am not saying it should not be).
I've dropped my instance of the patch. Thanks!
--
Kees Cook
Nikula
Reviewed-by: Kees Cook
--
Kees Cook
On Wed, Nov 02, 2022 at 12:52:32PM +0100, Rasmus Villemoes wrote:
> On 24/10/2022 22.11, Gwan-gyeong Mun wrote:
> > From: Kees Cook
> >
> > Implement a robust overflows_type() macro to test if a variable or
> > constant value would overflow another variable or type
On Sat, Oct 29, 2022 at 11:01:38AM +0300, Gwan-gyeong Mun wrote:
>
>
> On 10/29/22 10:32 AM, Kees Cook wrote:
> > On Sat, Oct 29, 2022 at 08:55:43AM +0300, Gwan-gyeong Mun wrote:
> > > Hi Kees,
> >
> > Hi! :)
> >
> > > I've updated to v5
ia the drm tree? Would you
rather I carry the non-drm changes in my tree instead?
>
--
Kees Cook
versions that are actually helpful beyond drm.
But I can see that it doesn't help to have a "do two things at the same
time" macro for the assignment checking.
--
Kees Cook
On Mon, Sep 26, 2022 at 01:17:18PM -0700, Nick Desaulniers wrote:
> + Arnd
>
> On Mon, Sep 26, 2022 at 12:11 PM Kees Cook wrote:
> > ---
> > v2:
> > - fix comment typo
> > - wrap clang pragma to avoid GCC warnings
> > - style nit cleanups
> > - re
o-developed-by: Gwan-gyeong Mun
Signed-off-by: Gwan-gyeong Mun
Signed-off-by: Kees Cook
---
v2:
- fix comment typo
- wrap clang pragma to avoid GCC warnings
- style nit cleanups
- rename __castable_to_type() to castable_to_type()
- remove prior overflows_type() definition
v1: https://
On Mon, Sep 26, 2022 at 06:57:53PM +0300, Gwan-gyeong Mun wrote:
>
>
> On 9/26/22 3:37 AM, Kees Cook wrote:
> > Add overflows_type() to test if a variable or constant value would
> > overflow another variable or type. This can be used as a constant
> > expression
avo A. R. Silva"
Cc: linux-harden...@vger.kernel.org
Cc: l...@lists.linux.dev
Co-developed-by: Gwan-gyeong Mun
Signed-off-by: Gwan-gyeong Mun
Signed-off-by: Kees Cook
---
include/linux/compiler.h | 1 +
include/linux/overflow.h | 48 +
lib/overfl
s
> overflow\n", \
> + #t1" __t1 = "#v, #t2" __t2", of ? "" : " not"); \
> + } \
These tests are excellent! I've adapted them a little bit to avoid some
of their internal redundancy. (i.e. the above blocks are basically
almost entire the same, etc).
-Kees
--
Kees Cook
I'm suspicious of the original design that has the same stuff
available twice in different places. (I have a dim memory of rdma
needing a refactoring like this too?)
Reviewed-by: Kees Cook
-Kees
--
Kees Cook
(which is
> introduced in C11) to generate a build break when the types are different
> and can be used to detect explicit build errors.
> Unlike the assert_type() macro, assert_typable() macro allows a constant
> value as the second argument.
>
> Suggested-by: Kees Cook
>
g type
> (Andrzej)
> v10: Remove a redundant type checking for a pointer. (Andrzej)
> Use updated check_add_overflow macro instead of __builtin_add_overflow
> (G.G)
> Add check_assign_user_ptr() macro and drop overflows_ptr() macro(Kees)
>
> Signed-off-by: Gwan-gyeong Mun
Acked-by: Kees Cook
--
Kees Cook
type
> + *
> + * It breaks compile if the argument value's type is not pgoff_t type.
> + */
> +#define exactly_pgoff_t(n) exact_type(pgoff_t, n)
Why specialize this? Just use assert_typable(pgoff_t, n) in the other
patches? It's almost the same amount to write. :)
--
Kees Cook
overflows_ptr() to use overflows_type() with the unsigned long type
> (Andrzej)
>
> Signed-off-by: Gwan-gyeong Mun
> Cc: Thomas Hellström
> Cc: Matthew Auld
> Cc: Nirmoy Das
> Cc: Jani Nikula
> Cc: Andi Shyti
> Cc: Andrzej Hajda
> Cc: Mauro Carvalho Chehab
>
t; + * Returns:
> > + * If the value would overflow the destination, it returns false.
> > + */
> > +#define safe_conversion(ptr, value) ({ \
> > + typeof(value) __v = (value); \
> > + typeof(ptr) __ptr = (ptr); \
> > + overflows_type(__v, *__ptr) ? 0 : ((*__ptr = (typeof(*__ptr))__v), 1); \
> > +})
I try to avoid "safe" as an adjective for interface names, since it
doesn't really answer "safe from what?" This looks more like "assign, but
zero when out of bounds". And it can be built from existing macros here:
if (check_add_overflow(0, value, ptr))
*ptr = 0;
I actually want to push back on this a bit, because there can still be
logic bugs built around this kind of primitive. Shouldn't out-of-bounds
assignments be seen as a direct failure? I would think this would be
sufficient:
#define check_assign(value, ptr)check_add_overflow(0, value, ptr)
And callers would do:
if (check_assign(value, &var))
return -EINVAL;
etc.
--
Kees Cook
t; + bi_next->num_planes = 0;
> + }
>
> bi->num_qgv_points = qi.num_points;
> bi->num_psf_gv_points = qi.num_psf_points;
(Some email path may be clogged; Nathan Chancellor has also sent email,
but I wanted to comment too.)
This patch solves https://github.com/ClangBuiltLinux/linux/issues/1626
And it's actually fixing a wild write as well: for folks where
"i < num_groups - 1" is false and they don't get "lucky" with a NULL
deref, this is writing to some address left over on the stack. :|
-Kees
--
Kees Cook
On Tue, Aug 23, 2022 at 04:32:10AM +0900, Gwan-gyeong Mun wrote:
> On 8/22/22 11:05 PM, Andrzej Hajda wrote:
> > On 18.08.2022 02:12, Kees Cook wrote:
> > > On Thu, Aug 18, 2022 at 01:07:29AM +0200, Andi Shyti wrote:
> > > > [...]
> > >
t; []
changes (when they are not erroneously being used within other
structures) is valid for all compilers. Flexible arrays are C99; it's
been 23 years. :)
But, yes, where we DO break stuff we need to workaround it, etc.
--
Kees Cook
UAPI_DEF_METHOD_NEEDS_FN(create_cq)),
which must also be assuming it's a header. So probably better to just
drop the driver_data field? I don't see anything using it (that I can
find) besides as a sanity-check that the field exists and is at the end
of the struct.
--
Kees Cook
: Implement I915_PERF_ADD/REMOVE_CONFIG
>interface")
>Signed-off-by: Nathan Chancellor
This matches my own investigation into the error. Thanks for putting the patch
together! :)
Reviewed-by: Kees Cook
--
Kees Cook
On Wed, Mar 02, 2022 at 12:18:45PM -0800, Linus Torvalds wrote:
> On Wed, Mar 2, 2022 at 12:07 PM Kees Cook wrote:
> >
> > I've long wanted to change kfree() to explicitly set pointers to NULL on
> > free. https://github.com/KSPP/linux/issues/87
>
> We've ha
le
with Coccinelle) and change them into something like kfree_no_null()
and redefine kfree() itself:
#define kfree_no_null(x) do { void *__ptr = (x); __kfree(__ptr); } while (0)
#define kfree(x) do { __kfree(x); x = NULL; } while (0)
--
Kees Cook
h treewide.patch
$ split-on-maintainer treewide.patch
$ ls 0*.patch
If you have a build log before the patch that spits out warnings, the
--build-log argument can extract those warnings on a per-file basis, too
(though this can be fragile).
--
Kees Cook
onally
shadows variables. :)
Another way to try to catch misused shadow variables is
-Wunused-but-set-varible, but it, too, has tons of false positives.
I tried to capture some of the rationale and research here:
https://github.com/KSPP/linux/issues/152
--
Kees Cook
gt; @@
> identifier S, member, array;
> type T1, T2;
> @@
>
> struct S {
> ...
> T1 member;
> T2 array[
> - 0
> ];
> };
These all look trivially correct to me. Only two didn't have the end of
the struct visible in the patch, and checking those showed t
On Fri, Dec 03, 2021 at 04:28:56PM +0100, Thierry Reding wrote:
> On Fri, Dec 03, 2021 at 01:25:17AM -0800, Kees Cook wrote:
> > The link_status array was not large enough to read the Adjust Request
> > Post Cursor2 register. Adjust the size to include it. Found with a
> >
47:51: note: while referencing 'link_status'
147 | u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZE],
|
~^~~~
Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor a
uot;drm/i915: Use a table for i915_init/exit (v2)")
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i915/i915_module.c | 37 +++---
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_module.c
b/drivers/gpu/drm/i915/i915_module.c
in
3])
>[130]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-skl6/igt@run...@aborted.html
>[131]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10239/shard-skl5/igt@run...@aborted.html
>[132]:
> https://intel-gfx-ci.01.or
")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c983044..6cc03b9e4321 100644
---
On Tue, Apr 13, 2021 at 08:54:06AM +0200, Peter Zijlstra wrote:
> On Mon, Apr 12, 2021 at 01:05:09PM -0700, Kees Cook wrote:
> > On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > > +struct vpr_data {
> > > + int (*fn)(pte_t pte, unsigned long addr, void
this would be:
static int check_present(unsigned long addr, unsigned long len)
unsigned long fail;
fail = verify_page_range(current->mm, addr, len, check_present_pte);
if (fail) {
pr_err("missing PTE:%lx\n", addr);
return -EI
On Tue, Apr 13, 2021 at 09:36:32AM +0200, Peter Zijlstra wrote:
> On Mon, Apr 12, 2021 at 01:05:09PM -0700, Kees Cook wrote:
> > On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > > +struct vpr_data {
> > > + int (*fn)(pte_t pte, unsigned long addr, void
itch to returning bad addr through verify_page_range(),
or have a by-reference value, etc:
unsigned long failed;
failed = verify_page_range(current->mm< addr, len, check_present_pte);
if (failed) {
pr_err("missing PTE:%lx\n",
(
This doesn't seem needed: only DRM uses it, and that's for error
reporting. I'd rather plumb back errors in a way to not have to add
another place in the kernel where we do func+arg stored calling.
--
Kees Cook
___
Intel
rvice file descriptor store.
>
> Note that some distributions such as Ubuntu are already enabling
> CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3046
> Signed-off-by: Chris Wilson
Thanks!
Re
the non-default
> > CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
> >
> > Note that some distributions such as Ubuntu are already enabling
> > CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp.
> >
> > References: https://g
uf) point to the same struct file. Since they depend on it for
> core functionality, lift SYS_kcmp out of the non-default
> CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
>
> Signed-off-by: Chris Wilson
> Cc: Kees Cook
> Cc: Andy Lutomirski
> Cc: Will Drewry
-through
All switch/case blocks must end in one of:
break;
fallthrough;
continue;
goto ;
return [expression];
[3] https://cwe.mitre.org/data/definitions/484.html
--
Kees Cook
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
inal series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)
--
Kees Cook
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
>
On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > > > This
On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > > > This
ngs are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!
It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily
t's the same form as container_of()
> > > and I think we need urgent agreement to not stall everything else so
> > > the most innocuous name is likely to get the widest acceptance.
> >
> > Kees,
> >
> > Will you be sending the newly proposed API to Linus? I have V2
> > which uses container_from()
> > ready to be sent out.
>
> I liked that James swapped the first two arguments so that it matches
> container_of(). Plus it's nice that when you have:
>
> struct whatever *foo = container_from(ptr, foo, member);
>
> Then it means that "ptr == &foo->member".
I'm a bit stalled right now -- the merge window was keeping me busy, and
this week is the Linux Plumbers Conference. This is on my list, but I
haven't gotten back around to it. If you want, feel free to send the
container_from() patch; you might be able to unblock this faster than me
right now. :)
-Kees
--
Kees Cook
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
1 - 100 of 152 matches
Mail list logo
