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
On May 31, 2025 3:23:04 AM PDT, Peter Zijlstra wrote:
>On Fri, May 30, 2025 at 10:48:47AM -0700, Kees Cook wrote:
>> On Fri, May 30, 2025 at 04:01:40PM +0200, Peter Zijlstra wrote:
>> > I'm not really concerned with performance here, but more with the size
>> >
*/
> + ud_type = decode_bug(addr, &ud_imm, &ud_len);
> +
> + return ud_type == BUG_UD2 ||
> + (ud_type >= BUG_WARN && ud_type <= BUG_WARN_END);
> +}
>
> static nokprobe_inline int
> do_trap_no_signal(struct task_struct *tsk, int trapnr, const char *str,
> @@ -305,6 +328,14 @@ static inline void handle_invalid_op(struct pt_regs
> *regs)
> ILL_ILLOPN, error_get_trap_addr(regs));
> }
>
> +static inline unsigned long pt_regs_val(struct pt_regs *regs, int nr)
> +{
> + int offset = pt_regs_offset(regs, nr);
> + if (WARN_ON_ONCE(offset < -0))
> + return 0;
> + return *((unsigned long *)((void *)regs + offset));
> +}
> +
> static noinstr bool handle_bug(struct pt_regs *regs)
> {
> unsigned long addr = regs->ip;
> @@ -334,6 +365,14 @@ static noinstr bool handle_bug(struct pt_regs *regs)
> raw_local_irq_enable();
>
> switch (ud_type) {
> + case BUG_WARN ... BUG_WARN_END:
> + int ud_reg = ud_type & 0xf;
> + int ud_rm = (ud_type >> 4) & 0xf;
> +
> + __warn_printk((const char *)(pt_regs_val(regs, ud_rm)),
> + pt_regs_val(regs, ud_reg));
> + fallthrough;
Yay, internal printk. :):)
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 62b3416f5e43..564513f605ac 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -8703,6 +8703,8 @@ void __init sched_init(void)
> preempt_dynamic_init();
>
> scheduler_running = 1;
> +
> + WARN(true, "Ultimate answer: %d\n", 42);
> }
>
> #ifdef CONFIG_DEBUG_ATOMIC_SLEEP
If any code would emit The Answer, it would be the scheduler. :)
--
Kees Cook
On Thu, May 29, 2025 at 11:02:19AM +0200, Peter Zijlstra wrote:
> On Wed, May 28, 2025 at 03:47:42PM -0700, Kees Cook wrote:
> > On Mon, May 26, 2025 at 01:27:51PM +, Alessandro Carminati wrote:
> > > Some unit tests intentionally trigger warning backtraces by passing bad
&
d walk of the
list...
This global may have the same problem. Why not use a static branch, or
is that just overkill?
-Kees
--
Kees Cook
ames and is intended for test usage only, performance is not a
> primary concern.
>
> Signed-off-by: Guenter Roeck
I like this -- it's very simple, it doesn't need to be fast-path, so
a linear list walker with strcmp is fine. Nice!
Reviewed-by: Kees Cook
--
Kees Cook
NULL,
as callers of fbcon_info_from_console() are trying to compare against
existing "info" pointers, so error handling should kick in correctly.
Reported-by: syzbot+a7de7b6e74357...@syzkaller.appspotmail.com
Closes:
https://lore.kernel.org/all/679d0a8f.050a0220.163cdc.000c....@google.com/
Signed-off
On Fri, May 02, 2025 at 03:34:47AM +0100, Al Viro wrote:
> On Thu, May 01, 2025 at 07:13:12PM -0700, Matthew Brost wrote:
> > On Thu, May 01, 2025 at 05:24:38PM -0700, Kees Cook wrote:
> > > Casting through a "void *" isn't sufficient to convince the randstruct
&g
On Thu, May 01, 2025 at 07:13:12PM -0700, Matthew Brost wrote:
> On Thu, May 01, 2025 at 05:24:38PM -0700, Kees Cook wrote:
> > Casting through a "void *" isn't sufficient to convince the randstruct
> > GCC plugin that the result is intentional. Instead operate th
/ttm_backup.c:21:16: note: randstruct: casting between
randomized structure pointer types (ssa): 'struct ttm_backup' and 'struct file'
21 | return (void *)file;
|^~~~
Suggested-by: Matthew Brost
Fixes: e7b5d23e5d47 ("drm/ttm: Provide a
On Thu, May 01, 2025 at 01:28:52PM -0700, Matthew Brost wrote:
> On Thu, May 01, 2025 at 12:59:03PM -0700, Kees Cook wrote:
> > Casting through a "void *" isn't sufficient to convince the randstruct
> > GCC plugin that the result is intentional. Instead operate th
/ttm_backup.c:21:16: note: randstruct: casting between
randomized structure pointer types (ssa): 'struct ttm_backup' and 'struct file'
21 | return (void *)file;
|^~~~
Fixes: e7b5d23e5d47 ("drm/ttm: Provide a shmem backup impleme
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
On Mon, Apr 28, 2025 at 10:18:34AM +0200, Louis Chauvet wrote:
>
>
> Le 26/04/2025 à 08:14, Kees Cook a écrit :
> > In preparation for making the kmalloc family of allocators type aware,
> > we need to make sure that the returned type from the allocation matches
> &g
On April 29, 2025 1:17:26 PM PDT, Helge Deller wrote:
>On 4/28/25 08:36, Geert Uytterhoeven wrote:
>> Hi Kees,
>>
>> On Sat, 26 Apr 2025 at 13:33, Helge Deller wrote:
>>> On 4/26/25 08:23, Kees Cook wrote:
>>>> In preparation for making the kmallo
ype.)
The assigned type is "struct dac_info *" but the returned type will be
"struct ics5342_info *", which has a larger allocation size. This is
by design, as struct ics5342_info contains struct dac_info as its first
member. Cast the allocation type to match the assignment.
Si
ype.)
The assigned type is "struct vkms_plane_state **", but the returned type
will be "struct drm_plane **". These are the same size (pointer size), but
the types don't match. Adjust the allocation type to match the assignment.
Signed-off-by: Kees Cook
---
Cc: Louis Chauv
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
ype.)
The assigned type is "uint64_t *", but the returned type, while 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: Maarten Lankhorst
Cc: Maxime Ripard
Cc: T
On Tue, Apr 22, 2025 at 09:45:39AM -0600, Gustavo A. R. Silva wrote:
> Use __member_size() to get the size of the flex-array member at compile
> time, instead of the convoluted expression `__struct_size(p) - sizeof(*p)`
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Coo
On Tue, Apr 22, 2025 at 09:44:56AM -0600, Gustavo A. R. Silva wrote:
> Use __member_size() to get the size of the flex-array member at compile
> time, instead of the convoluted expression `__struct_size(p) - sizeof(*p)`
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Coo
On Tue, Apr 22, 2025 at 09:22:26AM -0400, Alex Deucher wrote:
> On Mon, Apr 21, 2025 at 5:59 PM Kees Cook wrote:
> >
> > GCC really does not want to consider NULL (or near-NULL) addresses as
> > valid, so calculations based off of NULL end up getting range-tracked into
> &
7;:
cc1: note: source object is likely at address zero
As there isn't a sane way to convince it otherwise, hide vbios_str from
GCC's optimizer to avoid the warning so we can get closer to enabling
-Warray-bounds globally.
Signed-off-by: Kees Cook
---
Cc: Alex Deucher
Cc: "Christ
runl_nr; i++) {
> - if (!(args.v.runlists.data & BIT(i)))
> + if (!(runlists->data & BIT(i)))
> continue;
>
> - args.v.channels.mthd = NV_DEVICE_HOST_RUNLIST_CHANNELS;
> - args.v.channels.data = i;
> + channels->mthd = NV_DEVICE_HOST_RUNLIST_CHANNELS;
> + channels->data = i;
>
> - ret = nvif_object_mthd(device, NV_DEVICE_V0_INFO,
> &args, sizeof(args));
> - if (ret || args.v.channels.mthd ==
> NV_DEVICE_INFO_INVALID)
> + ret = nvif_object_mthd(device, NV_DEVICE_V0_INFO, args,
> +__struct_size(args));
> + if (ret || channels->mthd == NV_DEVICE_INFO_INVALID)
> return -ENODEV;
>
> - drm->runl[i].chan_nr = args.v.channels.data;
> + drm->runl[i].chan_nr = channels->data;
> drm->runl[i].chan_id_base = drm->chan_total;
> drm->runl[i].context_base =
> dma_fence_context_alloc(drm->runl[i].chan_nr);
>
Otherwise looks good.
-Kees
--
Kees Cook
)
>
> OK, I'll double check this.
Ah-ha, yes, I'm already testing this with KUnit:
struct bar {
int a;
u32 counter;
s16 array[];
};
...
DEFINE_RAW_FLEX(struct bar, two, array, 2);
...
KUNIT_EXPECT_EQ(test, sizeof(*two), sizeof(struct bar));
KUN
> Tested-by: Petr Mladek
> Signed-off-by: Aditya Garg
Reviewed-by: Kees Cook
--
Kees Cook
emoes
> Reviewed-by: Andy Shevchenko
> Reviewed-by: Petr Mladek
> Tested-by: Petr Mladek
> Signed-off-by: Hector Martin
Reviewed-by: Kees Cook
--
Kees Cook
> nouveau_fence_wait_uevent_handler, false,
> - &args.base, sizeof(args), &fctx->event);
> + args, __struct_size(args), &fctx->event);
>
> WARN_ON(ret);
> }
Looks good to me. Good replacement, including the __struct_size() use.
Reviewed-by: Kees Cook
--
Kees Cook
On Mon, Apr 07, 2025 at 01:57:48PM -0600, Gustavo A. R. Silva wrote:
>
>
> On 07/04/25 13:50, Kees Cook wrote:
> > On Thu, Apr 03, 2025 at 10:45:18AM -0600, Gustavo A. R. Silva wrote:
> > > -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> >
> @@ -60,8 +61,8 @@ nvif_fifo_runlists(struct nvif_device *device)
> }
>
> for (i = 0; i < device->runlists; i++) {
> - if (a->v.runlist[i].mthd != NV_DEVICE_INFO_INVALID)
> - device->runlist[i].engines = a->v.runlist[i].data;
> + if (runlist[i].mthd != NV_DEVICE_INFO_INVALID)
> + device->runlist[i].engines = runlist[i].data;
> }
>
> done:
> --
> 2.43.0
>
--
Kees Cook
>fault[fi]->access != FAULT_ACCESS_PREFETCH
> &&
> - !(args.phys[0] & NVIF_VMM_PFNMAP_V0_W)) ||
> + !(args->p.phys[0] & NVIF_VMM_PFNMAP_V0_W)) ||
> (buffer->fault[fi]->access != FAULT_ACCESS_READ &&
>buffer->fault[fi]->access != FAULT_ACCESS_WRITE &&
>buffer->fault[fi]->access != FAULT_ACCESS_PREFETCH
> &&
> - !(args.phys[0] & NVIF_VMM_PFNMAP_V0_A)))
> + !(args->p.phys[0] & NVIF_VMM_PFNMAP_V0_A)))
> break;
> }
>
LGTM, including the __struct_size() usage.
Reviewed-by: Kees Cook
--
Kees Cook
= u64_to_user_ptr(extension);
> + struct drm_xe_ext_set_property ext;
> + int err;
> + u32 idx;
> +
> + err = __copy_from_user(&ext, address, sizeof(ext));
Why is this safe? (i.e. why is it not copy_from_user()?) I see no
access_ok() check anywhere in the ioctl call path to this function.
--
Kees Cook
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
On March 13, 2025 10:42:10 AM PDT, Aditya Garg wrote:
>I already sent the 1st patch to DRM. I can rebase the test-printf bit to this
>tree. Sounds good?
Yeah, sounds good to me! Thanks :)
-Kees
--
Kees Cook
do whatever makes this easiest.
If patch #1 here were rebased onto the "kunit move" tree:
https://web.git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=for-next/move-kunit-tests
then I could just take it there?
-Kees
--
Kees Cook
oided by disabling
> CONFIG_KUNIT_SUPPRESS_BACKTRACE.
Yeah, as with my prior review, I'm a fan of this. It makes a bunch of my
very noisy tests much easier to deal with.
-Kees
--
Kees Cook
freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@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
> Cc: linux-harden...@vger.kernel.org
> Signed-off-by: Thorsten Blum
Yup, the adapter var is already zeroed out, so even if NUL padding is
needed, it is already present.
Reviewed-by: Kees Cook
--
Kees Cook
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
use? I use Mutt and K-9 Mail, and I need to check
the quote prefix settings in both...)
-Kees
--
Kees Cook
s, n) + n)
>
> In shadow utils, I did a global replacement of all buf[...] = '\0'; by
> strcpy(..., "");. It ends up being optimized by the compiler to the
> same code (at least in the experiments I did).
Just to repeat what's already been said: no, please, don't complicate
this with yet more wrappers. And I really don't want to add more str/mem
variants -- we're working really hard to _remove_ them. :P
-Kees
--
Kees Cook
+ * called. Therefore, we need to add a null termimator.
> + */
> + buf[len - 1] = '\0';
> + }
> return buf;
> }
> EXPORT_SYMBOL(kstrdup);
> --
> 2.43.5
>
--
Kees Cook
On Wed, Aug 28, 2024 at 05:09:08PM +0200, Alejandro Colomar wrote:
> Hi Kees,
>
> On Wed, Aug 28, 2024 at 06:48:39AM GMT, Kees Cook wrote:
>
> [...]
>
> > >Thank you for your suggestion. How does the following commit log look
> > >to you? Does it meet your
/lore.kernel.org/all/2jxak5v6dfxlpbxhpm3ey7oup4g2lnr3ueurfbosf5wdo65dk4@srb3hsk72zwq
>Signed-off-by: Yafang Shao
>Cc: Alexander Viro
>Cc: Christian Brauner
>Cc: Jan Kara
>Cc: Eric Biederman
>Cc: Kees Cook
>Cc: Alexei Starovoitov
>Cc: Matus Jokay
>Cc: Alejandro
gt; > > [0]
>> > > Link:
>> > > https://lore.kernel.org/all/CAHk-=whwtuc-ajmgjveaetkomemfstwkwu99v7+b6ayhmma...@mail.gmail.com/
>> > > Suggested-by: Alejandro Colomar
>> > > Link:
>> > > https://lore.kernel.org/all/2
dex;
The stack variable (was before and is again) already zero-initialized,
so the "= 0" line shouldn't be needed.
But neither of these comments are show-stoppers, IMO.
Reviewed-by: Kees Cook
--
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
On July 12, 2024 2:59:30 AM PDT, Jocelyn Falempe wrote:
>Gentle ping, I need reviews from powerpc, usermod linux, mtd, pstore and
>hyperv, to be able to push it in the drm-misc tree.
Oops, I thought I'd Acked already!
Acked-by: Kees Cook
And, yeah, as mpe said, you're
On Wed, Jul 03, 2024 at 10:22:11AM +0200, Petr Mladek wrote:
> On Wed 2024-07-03 09:57:26, Jocelyn Falempe wrote:
> >
> >
> > On 02/07/2024 22:29, Kees Cook wrote:
> > > On Tue, Jul 02, 2024 at 02:26:04PM +0200, Jocelyn Falempe wrote:
> > > > kmsg_dump
son, like "sysrq triggered crash"
> or "VFS: Unable to mount root fs on " on the drm panic screen.
>
> v2:
> * Use a struct kmsg_dump_detail to hold the reason and description
> pointer, for more flexibility if we want to add other parameters.
&g
n't
any "new" information here that should be captured somehow.
Thanks!
--
Kees Cook
c
@@ -8,7 +8,7 @@
#include
static void kmsg_dumper_stdout(struct kmsg_dumper *dumper,
- enum kmsg_dump_reason reason)
+ struct kmsg_dump_detail *detail)
{
static struct kmsg_dump_iter iter;
static DEFINE_SPINLOCK(lock);
--
Kees Cook
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
been enabled for the drm subsystem and since Werror is
> enabled for test builds.
>
> Rearrange arithmetic and use check_add_overflow() for validating the
> allocation size to avoid the overflow.
>
> Fixes: a61ddb4393ad ("drm: enable (most) W=1 warnings by default across the
> subsys
aling()
>
> Link:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
> [1]
> Link: https://github.com/KSPP/linux/issues/160 [2]
> Signed-off-by: Christophe JAILLET
Yes please! :)
Reviewed-by: Kees Cook
--
Kees Cook
d wrap around, even though the allocation may not.
Better yet, since "sizeof(*args) + size" is repeated 3 times in the
function, I'd recommend:
...
u32 args_size;
if (check_add_overflow(sizeof(*args), size, &args_size))
return -ENOMEM;
if (args_size > sizeof(stack)) {
if (!(args = kmalloc(args_size, GFP_KERNEL)))
return -ENOMEM;
} else {
args = (void *)stack;
}
...
ret = nvif_object_ioctl(object, args, args_size, NULL);
This will catch the u32 overflow to nvif_object_ioctl(), catch an
allocation underflow on 32-bits systems, and make the code more
readable. :)
-Kees
--
Kees Cook
On Sat, May 04, 2024 at 12:03:18AM +0100, Al Viro wrote:
> On Fri, May 03, 2024 at 03:46:25PM -0700, Kees Cook wrote:
> > On Fri, May 03, 2024 at 02:52:38PM -0700, Linus Torvalds wrote:
> > > That means that the file will be released - and it means that you have
> > > v
fence? But
looking through dma_fence_signal_timestamp_locked(), I don't see
anything about resv nor somehow looking into other fence cb_list
contents...
--
Kees Cook
On Fri, May 03, 2024 at 12:59:52PM -0700, Kees Cook wrote:
> So, yeah, I can't figure out how eventpoll_release() and epoll_wait()
> are expected to behave safely for .poll handlers.
>
> Regardless, for the simple case: it seems like it's just totally illegal
> to use get
On Fri, May 03, 2024 at 01:35:09PM -0600, Jens Axboe wrote:
> On 5/3/24 1:22 PM, Kees Cook wrote:
> > On Fri, May 03, 2024 at 12:49:11PM -0600, Jens Axboe wrote:
> >> On 5/3/24 12:26 PM, Kees Cook wrote:
> >>> Thanks for doing this analysis! I suspect at least a star
On Fri, May 03, 2024 at 12:49:11PM -0600, Jens Axboe wrote:
> On 5/3/24 12:26 PM, Kees Cook wrote:
> > Thanks for doing this analysis! I suspect at least a start of a fix
> > would be this:
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-b
+++ b/include/linux/fs.h
@@ -1040,7 +1040,8 @@ struct file_handle {
static inline struct file *get_file(struct file *f)
{
- atomic_long_inc(&f->f_count);
+ long prior = atomic_long_fetch_inc_relaxed(&f->f_count);
+ WARN_ONCE(!prior, "struct file::f_count incremented from zero;
use-after-free condition present!\n");
return f;
}
What's the right way to deal with the dmabuf situation? (And I suspect
it applies to get_dma_buf_unless_doomed() as well...)
-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
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
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
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
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
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
s patch hasn't been backported yet...
> Anyway, thanks for the pointer!
> I'll apply your patch in the next round for fbdev.
Hi! I haven't seen this show up in -next yet. Have you had a chance to
pick it up?
There are also these too:
https://lore.kernel.org/all/20240320-strncpy-drivers-video-fbdev-fsl-diu-fb-c-v1-1-3cd3c012f...@google.com/
https://patchwork.kernel.org/project/linux-hardening/patch/20240320-strncpy-drivers-video-fbdev-uvesafb-c-v1-1-fd6af3766...@google.com/
https://patchwork.kernel.org/project/linux-hardening/patch/20240320-strncpy-drivers-video-hdmi-c-v1-1-f9a08168c...@google.com/
I can toss all of these into the hardening tree if that makes it easier
for you?
Thanks!
-Kees
--
Kees Cook
ces
> arm64: Add support for suppressing warning backtraces
> loongarch: Add support for suppressing warning backtraces
> parisc: Add support for suppressing warning backtraces
> s390: Add support for suppressing warning backtraces
> sh: Add support for suppressi
strings = (char *)&rpc->entries[NV_GSP_REG_NUM_ENTRIES];
...
memcpy(strings, r535_registry_entries[i].name, name_len);
Signed-off-by: Kees Cook
---
Cc: Karol Herbst
Cc: Lyude Paul
Cc: Danilo Krummrich
Cc: David Airlie
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: B
/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> [1]
> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
> [2]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kernel.org
> Signed-off-by: Justin Stitt
Reviewed-by: Kees Cook
--
Kees Cook
npages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kernel.org
> Signed-off-by: Justin Stitt
Reviewed-by: Kees Cook
--
Kees Cook
ated-strings
> [1]
> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kernel.org
> Signed-off-by: Justin Stitt
Reviewed-by: Kees Cook
--
Kees Cook
ps://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
> [2]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kernel.org
> Signed-off-by: Justin Stitt
Yup, looks correct.
Reviewed-by: Kees Cook
--
Kees Cook
On Tue, Mar 12, 2024 at 10:02:59AM -0700, Guenter Roeck wrote:
> Document API functions for suppressing warning backtraces.
>
> Signed-off-by: Guenter Roeck
Reviewed-by: Kees Cook
--
Kees Cook
t; the affected architectures / platforms fixed.
>
> Signed-off-by: Guenter Roeck
Reviewed-by: Kees Cook
--
Kees Cook
;suppressed_warnings, node) {
> - if (!strcmp(function, warning->function))
> + if (!strcmp(function, warning->function)) {
> + warning->counter++;
> return true;
> + }
> }
> return false;
> }
> --
> 2.39.2
>
Reviewed-by: Kees Cook
--
Kees Cook
> Solve the problem by providing a means to identify and suppress specific
> warning backtraces while executing test code.
>
> Cc: Dan Carpenter
> Cc: Daniel Diaz
> Cc: Naresh Kamboju
> Cc: Kees Cook
> Signed-off-by: Guenter Roeck
Yup, this looks fine to me.
Reviewed-by: Kees Cook
--
Kees Cook
ries could add counters or something that
KUnit could examine. E.g. I did this manually for some fortify tests:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/hardening&id=4ce615e798a752d4431fcc52960478906dec2f0e
-Kees
--
Kees Cook
ference to `__ubsan_handle_out_of_bounds'
This is fixed here and is waiting to land:
https://lore.kernel.org/linux-hardening/20240130232717.work.088-k...@kernel.org/
-Kees
--
Kees Cook
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
ian König
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Kees Cook
---
drivers/dma-buf/dma-buf.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.
nel.org/linus/68df3755e383e6fecf2354a67b08f92f18536594 [1]
Link: https://github.com/KSPP/linux/issues/26 [2]
Link: https://github.com/KSPP/linux/issues/27 [3]
Link: https://github.com/KSPP/linux/issues/344 [4]
Cc: Greg Kroah-Hartman
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/char/agp/
eedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/vc4/vc4_validate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_validate.c
b/drivers/gpu/drm/vc4/vc4_validate.c
index 9affba9c58b3..677d9975f888 100644
--- a/drivers/gpu/drm/vc4/vc4_validate.c
l
Cc: Danilo Krummrich
Cc: David Airlie
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: Julia Lawall
Cc: Jiang Jian
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 6 --
1 fi
vrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@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: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mm
Lankhorst
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/vc4/vc4_validate.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_validate.c
b/driver
--
> Nathan Chancellor
>
Excellent! Thanks for doing this. I spot checked a handful I was
familiar with and everything looks good to me.
Reviewed-by: Kees Cook
--
Kees Cook
1 - 100 of 708 matches
Mail list logo
