On Tue, Jun 04, 2024 at 04:13:32PM -0600, Tycho Andersen wrote:
> On Tue, Jun 04, 2024 at 04:02:28PM +0100, Simon Horman wrote:
> > On Fri, May 31, 2024 at 12:14:56PM -0700, Kees Cook wrote:
> > > + for (idx = 0; idx < ARRAY_SIZE(kmalloc_caches[KMALLOC_NORMAL]); idx++) {
On Tue, Jun 04, 2024 at 10:09:43AM -0700, Nikita Zhandarovich wrote:
> Hi,
>
> On 6/4/24 07:15, Jiri Kosina wrote:
> > On Tue, 4 Jun 2024, Kees Cook wrote:
> >
> >> This isn't the right solution. The problem is that hid_class_descriptor
> >> is a flexible
e flexible array:
struct hid_descriptor {
__u8 bLength;
__u8 bDescriptorType;
__le16 bcdHID;
__u8 bCountryCode;
__u8 bNumDescriptors;
struct hid_class_descriptor desc[1];
} __attribute__ ((packed));
This likely needs to be:
struct hid_class_descriptor desc[] __counted_by(bNumDescriptors);
And then check for any sizeof() uses of the struct that might have changed.
--
Kees Cook
memparse(p+1, );
>+ if (*p != ':')
>+ return -EINVAL;
>+
>+ start = memblock_phys_alloc(size, align);
>+ if (!start)
>+ return -ENOMEM;
>+
>+ p++;
>+ err = reserved_mem_add(start, size, p);
>+ if (err) {
>+ memblock_phys_free(start, size);
>+ return err;
>+ }
>+
>+ p += strlen(p);
>+
>+ return *p == '\0' ? 0: -EINVAL;
>+}
>+__setup("reserve_mem=", reserve_mem);
>+
> #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_ARCH_KEEP_MEMBLOCK)
> static const char * const flagname[] = {
> [ilog2(MEMBLOCK_HOTPLUG)] = "HOTPLUG",
--
Kees Cook
On Mon, Jun 03, 2024 at 07:06:15PM +0200, Vlastimil Babka wrote:
> On 5/31/24 9:14 PM, Kees Cook wrote:
> > Introduce CONFIG_SLAB_BUCKETS which provides the infrastructure to
> > support separated kmalloc buckets (in the follow kmem_buckets_create()
> > patches and future cod
type = *(u16 *)(regs->ip + offset);
if ((type & 0xFF) != 0x40)
return;
type = (type >> 8) & 0xFF;
pr_crit("%s at %pS\n", report_ubsan_failure(regs, type), (void
*)regs->ip);
--
Kees Cook
and make it a hard failure if such
cases are introduced in the future. This hasn't been a particularly
friendly solution in the past, though, as the fortify routines do tend
to grow additional coverage over time, so there may be future cases that
do trip the runtime checking...
--
Kees Cook
On Fri, May 31, 2024 at 10:49:47PM +0200, Borislav Petkov wrote:
> On Fri, May 31, 2024 at 01:46:37PM -0700, Kees Cook wrote:
> > Please do not do this. It still benefits from compile-time sanity
> > checking.
>
> Care to elaborate how exactly it benefits?
Because whe
On Fri, May 31, 2024 at 12:51:29PM -0400, Kent Overstreet wrote:
> On Fri, May 31, 2024 at 09:48:49AM -0700, Kees Cook wrote:
> > On Fri, May 24, 2024 at 11:01:40AM -0400, Kent Overstreet wrote:
> > > On Wed, Apr 24, 2024 at 02:40:59PM -0700, Kees Cook wrote:
> > > &
On Fri, May 31, 2024 at 09:08:16PM +0200, Borislav Petkov wrote:
> On Fri, May 31, 2024 at 09:53:28AM -0700, Kees Cook wrote:
> > Under CONFIG_FORTIFY_SOURCE, the boot code *does* still uses
> > fortify-string.h. It lets us both catch mistakes we can discover at
> > c
-writeup.html [3]
Link: https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html [4]
Link:
https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html
[5]
Link: https://zplin.me/papers/ELOISE.pdf [6]
Link: https://syst3mfailure.io/wall-of-perdition/ [7]
Signed-off-by: Kees Cook
://github.com/a13xp0p0v/kernel-hack-drill/blob/master/drill_exploit_uaf.c
[4]
Signed-off-by: Kees Cook
---
Cc: "GONG, Ruiqi"
Cc: Xiu Jianfeng
Cc: Suren Baghdasaryan
Cc: Kent Overstreet
Cc: Jann Horn
Cc: Matteo Rizzo
Cc: jvoisin
Cc: linux...@kvack.org
---
mm/util.c | 14 +++
Encapsulate the concept of a single set of kmem_caches that are used
for the kmalloc size buckets. Redefine kmalloc_caches as an array
of these buckets (for the different global cache buckets).
Signed-off-by: Kees Cook
---
Cc: Vlastimil Babka
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David
nk:
https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html
[2]
Link:
https://lore.kernel.org/lkml/20230915105933.495735-1-matteori...@google.com/ [3]
Signed-off-by: Kees Cook
---
Cc: Vlastimil Babka
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: j
Plumb kmem_buckets arguments through kvmalloc_node_noprof() so it is
possible to provide an API to perform kvmalloc-style allocations with
a particular set of buckets. Introduce kvmalloc_buckets_node() that takes a
kmem_buckets argument.
Signed-off-by: Kees Cook
---
Cc: Vlastimil Babka
Cc
g/blog/2023/07-prctl-anon_vma_name-an-amusing-heap-spray/ [1]
Link: https://duasynt.com/blog/linux-kernel-heap-spray [2]
Link: https://etenal.me/archives/1336 [3]
Link:
https://github.com/a13xp0p0v/kernel-hack-drill/blob/master/drill_exploit_uaf.c
[4]
Thanks!
-Kees
Kees Cook (6):
The actual extern
functions can then been built without the argument, and the internals
fall back to the global kmalloc buckets unconditionally.
Signed-off-by: Kees Cook
---
Cc: Vlastimil Babka
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: jvoisin
Cc: Andrew Morton
__kmalloc_node() is considered an "internal" function to the Slab, so
drop it from explicit testing.
Signed-off-by: Kees Cook
---
Cc: Vlastimil Babka
Cc: linux...@kvack.org
Cc: linux-hardening@vger.kernel.org
---
lib/fortify_kunit.c | 3 ---
1 file changed, 3 deletions(-)
diff -
took guidance from him :)
>
> The more important question is how does the decompressor build even know of
> this symbol? And then make it forget it again instead of adding silly
> prototypes...
Under CONFIG_FORTIFY_SOURCE, the boot code *does* still uses
fortify-string.h. It lets us both catch mistakes we can discover at
compile and will catch egregious runtime mistakes, though the reporting
is much simpler in the boot code.
--
Kees Cook
On Fri, May 24, 2024 at 11:01:40AM -0400, Kent Overstreet wrote:
> On Wed, Apr 24, 2024 at 02:40:59PM -0700, Kees Cook wrote:
> > To be able to choose which buckets to allocate from, make the buckets
> > available to the lower level kmalloc interfaces by adding them as the
>
On Fri, May 24, 2024 at 03:38:58PM +0200, Vlastimil Babka wrote:
> On 4/24/24 11:40 PM, Kees Cook wrote:
> > To be able to choose which buckets to allocate from, make the buckets
> > available to the lower level kmalloc interfaces by adding them as the
> > first argum
On Fri, May 24, 2024 at 10:54:58AM -0400, Kent Overstreet wrote:
> On Wed, Apr 24, 2024 at 02:40:57PM -0700, Kees Cook wrote:
> > Hi,
> >
> > Series change history:
> >
> > v3:
> > - clarify rationale and purpose in commit log
> > - rebase to
On Fri, May 24, 2024 at 03:43:33PM +0200, Vlastimil Babka wrote:
> On 4/24/24 11:41 PM, Kees Cook wrote:
> > Dedicated caches are available for fixed size allocations via
> > kmem_cache_alloc(), but for dynamically sized allocations there is only
> > the global kmalloc
or("detected buffer overflow");
}
+#endif
Jeff, can you test this? (I still haven't been able to reproduce the
warning.)
--
Kees Cook
gt; > > + type = (type >> 8) & 0xFF;
> > > > > + }
> > > > > + pr_crit("%s at %pS\n", report_ubsan_failure(regs, type),
> > > > > (void *)regs->ip);
> > > > > +
> > > > > + return BUG_TRAP_TYPE_NONE;
> > > > > +}
> > > >
> > > > Shouldn't this return BUG_TRAP_TYPE_WARN?
> > >
> > > So as far as I understand, UBSAN trap mode never warns. Perhaps it does on
> > > arm64, although it calls die() so I am unsure. Maybe the condition in
> > > handle_bug() should be rewritten in the case of UBSAN ud1s? Do you have
> > > any
> > > suggestions?
> >
> > AFAIK on arm64 it's basically a kernel OOPS.
> >
> > The main thing I just wanted to point out though is that your newly added
> > branch
> >
> > > if (handle_ubsan_failure(regs, insn) == BUG_TRAP_TYPE_WARN) {
> >
> > will never be taken, because I don't see where handle_ubsan_failure()
> > returns BUG_TRAP_TYPE_WARN.
> >
>
> Initially I wrote this with some symmetry to the KCFI checks nearby, but I
> was unsure if this would be considered handled or not.
Yeah, that seemed like the right "style" to me too. Perhaps, since it
can never warn, we could just rewrite it so it's a void function avoid
the checking, etc.
--
Kees Cook
On Wed, May 29, 2024 at 10:09:45AM -0700, Jeff Johnson wrote:
> On 5/29/2024 9:55 AM, Kees Cook wrote:
> > On Wed, May 29, 2024 at 07:36:25AM -0700, Jeff Johnson wrote:
> >> 'make W=1 C=1' on x86 gives the warning:
> >> arch/x86/boot/compressed/misc.c:535:6: warni
a prototype to a header file that is only
> for the benefit of the callee and is not the prototype/header used by the
> caller, in this case the one in include/linux/fortify-string.h
The stuff in boot/ doesn't tend to include fortify-string.h (since it's
sort of "outside" the kernel), hence the need for additional prototypes.
--
Kees Cook
Reported-by: syzbot+50835f73143cc2905...@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/19f4c00619192...@google.com/
Fixes: 744a56389f73 ("ext4: replace deprecated strncpy with alternatives")
Signed-off-by: Kees Cook
---
Cc: "Theodore Ts'o"
Cc: Ju
.
-Kees
[1]
https://lore.kernel.org/linux-hardening/20240519190422.work.715-k...@kernel.org/
Kees Cook (2):
exec: Add KUnit test for bprm_stack_limits()
exec: Avoid pathological argc, envc, and bprm->p values
MAINTAINERS | 2 +
fs/Kconfig.binfmt | 8 +++
fs/exec.c |
Make sure nothing goes wrong with the string counters or the bprm's
belief about the stack pointer. Add checks and matching self-tests.
For 32-bit validation, this was run under 32-bit UML:
$ tools/testing/kunit/kunit.py run --make_options SUBARCH=i386 exec
Signed-off-by: Kees Cook
---
Cc: Eric
Since bprm_stack_limits() operates with very limited side-effects, add
it as the first exec.c KUnit test. Add to Kconfig and adjust MAINTAINERS
file to include it.
Tested on 64-bit UML:
$ tools/testing/kunit/kunit.py run exec
Signed-off-by: Kees Cook
---
Cc: Eric Biederman
Cc: Justin Stitt
Cc
When memcmp() returns a non-zero value, only the signed bit has any
meaning. The actual value may differ between implementations.
Reported-by: Nathan Chancellor
Closes: https://github.com/ClangBuiltLinux/linux/issues/2025
Tested-by: Nathan Chancellor
Signed-off-by: Kees Cook
---
Cc: linux
_host_cmd
> *cmd)
> out_meta->callback = cmd->callback;
>
> out_cmd->hdr.cmd = cmd->id;
> - memcpy(_cmd->cmd.payload, cmd->data, cmd->len);
> + memcpy(_cmd->hdr.data, cmd->data, cmd->len);
>
> /* At this point, the out_cmd now has all of the incoming cmd
>* information */
--
Kees Cook
palatable way to leave the behavior unchanged while gaining
compiler coverage.
-Kees
[1] https://lore.kernel.org/linux-hardening/202405171329.019F2F566C@keescook/
--
Kees Cook
for the compiler, though.
I think a great example recently was Peter's work creating "cleanup.h".
This feature totally changes how people have to read a function (increase
in burden), leans heavily on compiler behaviors, and shifts the burden
of correctness away from the human. It's great! But it's also _very
different_ from traditional/old-school C.
-Kees
--
Kees Cook
uld inform us what further steps
down this path can look like.
-Kees
--
Kees Cook
rojects for
> older kernel releases. Would such an extension be useful to show new
> defects in addition to the current release testing?
The only one we (lightly) manage right now is the linux-next scanner. If
other folks want to host scanners for -stable kernels, that would be
interesting, yes.
-Kees
--
Kees Cook
ves
>the UB from signed overflow by mandating 2s complement.
I am a broken record. :) This is _not_ about undefined behavior.
This is about finding a way to make the intent of C authors unambiguous. That
overflow wraps is well defined. It is not always _desired_. C has no way to
distinguish between the two cases.
-Kees
--
Kees Cook
...@kernel.org
Fixes: 918327e9b7ff ("ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL")
Signed-off-by: Kees Cook
---
Cc: Marco Elver
Cc: Andrey Konovalov
Cc: Andrey Ryabinin
Cc: kasan-...@googlegroups.com
Cc: linux-hardening@vger.kernel.org
---
lib/Kconfig.ubsan | 1 +
1 file changed, 1
ed-off-by: Masahiro Yamada
Oh, er, we probably want the reverse of this: add a depends to
CONFIG_UBSAN, otherwise we may end up trying to build with UBSAN when it
is not supported. That was my intention -- it looks like I missed adding
the line. :(
-Kees
--
Kees Cook
UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE
> (for strcpy/memcpy-family functions).
>
> Cc: Mikulas Patocka
> Cc: Kees Cook
> Cc: "Gustavo A. R. Silva"
> Cc: Nathan Chancellor
> Cc: Nick Desaulniers
> Cc: Justin Stitt
> Cc: linux-ker...@vger.kern
On Mon, May 13, 2024 at 10:06:59PM +, Justin Stitt wrote:
> On Mon, May 13, 2024 at 01:01:57PM -0700, Kees Cook wrote:
> > On Thu, May 09, 2024 at 11:42:07PM +, Justin Stitt wrote:
> > > fs/read_write.c | 18 +++---
> > > fs/remap_range.c | 12
On Tue, May 14, 2024 at 07:39:31AM +0900, Masahiro Yamada wrote:
> On Tue, May 14, 2024 at 3:48 AM Kees Cook wrote:
> > I am worried about the use of "guess" and "most", though. :) Before, we
> > had some clear opt-out situations, and now it's more of a si
@@ -44,17 +44,17 @@ static int generic_remap_checks(struct file *file_in,
> loff_t pos_in,
> if (!IS_ALIGNED(pos_in, bs) || !IS_ALIGNED(pos_out, bs))
> return -EINVAL;
>
> - /* Ensure offsets don't wrap. */
> - if (pos_in + count < pos_in || pos_out + count < pos_out)
> - return -EINVAL;
> + if (check_add_overflow(pos_in, count, _sum) ||
> + check_add_overflow(pos_out, count, _sum))
> + return -EOVERFLOW;
Yeah, this is a good error code change. This is ultimately exposed via
copy_file_range, where this error is documented as possible.
-Kees
--
Kees Cook
, the code is more safer.
>
> This code was detected with the help of Coccinelle, and audited and
> modified manually.
>
> 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: Erick Archer
Thanks!
Reviewed-by: Kees Cook
--
Kees Cook
2)'
> 2251 static ssize_t
> 2252 store_temp_offset(struct device *dev, struct device_attribute *attr,
> 2253const char *buf, size_t count)
> 2254 {
> 2255 struct nct6775_data *data = dev_get_drvdata(dev);
> 2256 struct sensor_device_attribute *sattr =
> to_sensor_dev_attr(attr);
> 2257 int nr = sattr->index;
> 2258 long val;
> 2259 int err;
> 2260
> 2261 err = kstrtol(buf, 10, );
> 2262 if (err < 0)
> 2263 return err;
> 2264
> 2265 val = clamp_val(DIV_ROUND_CLOSEST(val, 1000), -128, 127);
> ^^
> Overflow and then clamp.
Looks like DIV_ROUND_CLOSEST() needs to be made sane and use more modern
helpers (it appears to be doing open-coded is_signed(), wants
check_*_overflow(), etc).
>
> 2266
> 2267 mutex_lock(>update_lock);
>
> regards,
> dan carpenter
-Kees
--
Kees Cook
ccinelle, and audited and
> modified manually.
>
> Link:
> https://www.kernel.org/doc/html/next/process/deprecated.html#zero-length-and-one-element-arrays
> [1]
> Link:
> https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arg
n coded
> > > arithmetic". It should have been in a separate patch.
> >
> > +1, please split these changes into its own patch so we can apply it
> > separately.
>
> Ok, no problem. Also, I will simplify the "bacpy" lines with direct
> assignments as Kees suggested:
>
>di[n].src = dev->src;
>di[n].dst = dev->dst;
>
> instead of:
>
>bacpy([n].src, >src);
>bacpy([n].dst, >dst);
I think that's a separate thing and you can leave bacpy() as-is for now.
--
Kees Cook
ude arch/x86/entry/vdso/vma.o into GCOV, KCOV
> - include arch/x86/um/vdso/vma.o into KASAN, GCOV, KCOV
I would agree that these cases are all likely desirable.
Did you find any cases where you found that instrumentation was _removed_
where not expected?
-Kees
--
Kees Cook
es all the
types by examining the arguments and avoids repeating the destination
argument. So this would become:
wrapping_assign_add(sum, buf[i]);
Still not as clean as "+=", but at least more readable than the
alternatives and leaves no question about wrapping intent.
-Kees
[1] https://lore.kernel.org/lkml/202405081949.0565810E46@keescook/
--
Kees Cook
his way, the code is more readable, idiomatic and safer.
>
> This code was detected with the help of Coccinelle, and audited and
> modified manually.
>
> 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: Erick Archer
Looks right to me. Thanks!
Reviewed-by: Kees Cook
--
Kees Cook
more readable, idiomatic and safer.
>
> This code was detected with the help of Coccinelle, and audited and
> modified manually.
>
> Link:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
> [1]
> Link: h
Hi,
>
> This patch can be considered v4 of this other one [1]. However, since
> the patch has completely changed due to the addition of the flex array,
> I have decided to make a new series and remove the "Reviewed-by:" tag
> by Gustavo A. R. Silva and Kees cook.
>
>
ed strncpy with strscpy_pad
Kees Cook (21):
string: Prepare to merge strscpy_kunit.c into string_kunit.c
string: Merge strscpy KUnit tests into string_kunit.c
string: Prepare to merge strcat KUnit tests into string_kunit.c
string: Merge strcat KUnit tests into string_kunit.c
strin
y harmless
overflows), and then dig into implicit integer truncation next.
Thank you for spending the time to look at all of this. It's a big topic
that many people feel very strongly about, so it's good to get some
"approved" direction on it. :)
-Kees
[1] These are NOT meant to be upstreamed as-is. We have idiom exclusions
to deal with, etc, but here's the tree I haven't refreshed yet:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=dev/v6.8-rc2/signed-trunc-sanitizer
[2] c14679d7005a ("wifi: cfg80211: Annotate struct cfg80211_mbssid_elems with
__counted_by")
--
Kees Cook
gain this
correctness coverage? It's accepted that there will be a non-trivial
impact, and I agree we can start to consider how to optimize
implementations. But for now I'd like to solve for how to even represent
arithmetic overflow intent at the source level.
-Kees
--
Kees Cook
On Wed, May 08, 2024 at 01:07:38PM -0700, Linus Torvalds wrote:
> On Wed, 8 May 2024 at 12:45, Kees Cook wrote:
> >
> > On Wed, May 08, 2024 at 10:52:44AM -0700, Linus Torvalds wrote:
> > > Example:
> > >
> > >static inline u32 __hash_32_generic(u3
On Wed, May 08, 2024 at 10:52:44AM -0700, Linus Torvalds wrote:
> On Tue, 7 May 2024 at 16:27, Kees Cook wrote:
> [...]
> Put another way the absolute first and fundamental thing you should
> look at is to make sure tools don't complain about sane behavior.
Agreed, and I expli
rs here but I did not
> want to change more than what was necessary.
>
> Link: https://github.com/llvm/llvm-project/pull/82432 [1]
> Closes: https://github.com/KSPP/linux/issues/357
> Cc: linux-hardening@vger.kernel.org
> Signed-off-by: Justin Stitt
Yeah, this looks good. Thanks!
Reviewed-by: Kees Cook
--
Kees Cook
.
Suggested-by: "Thomas Weißschuh"
Link:
https://lore.kernel.org/lkml/20240423-sysctl-const-handler-v3-11-e0beccb83...@weissschuh.net/
[1]
Signed-off-by: Kees Cook
---
Cc: "Thomas Weißschuh"
Cc: Joel Granados
Cc: Luis Chamberlain
Cc: Andy Lutomirski
Cc: Will Drewry
---
for __counted_by_{le, be}
https://git.kernel.org/kees/c/6d305cbef1aa
Take care,
--
Kees Cook
...
return cdi->ops->select_speed(cdi, arg);
}
And the arg there is unsigned long (?!).
So I think probably the prototype should be changed to unsigned long,
and then it can clamp the "speed" argument:
+ /* avoid exceeding the max speed or overflowing integer bounds */
; sum for the following check.
>
> Link: https://github.com/llvm/llvm-project/pull/82432 [1]
> Closes: https://github.com/KSPP/linux/issues/356
> Cc: linux-hardening@vger.kernel.org
> Signed-off-by: Justin Stitt
I think this makes the checking more reading too. Thanks
Reviewed-by: Kees Cook
--
Kees Cook
/linux/issues/354
> Cc: linux-hardening@vger.kernel.org
> Signed-off-by: Justin Stitt
Much more idiomatic. :)
Reviewed-by: Kees Cook
--
Kees Cook
rk. Many coverage areas are excluded, but the scope of what's
needed is observable. Notably, this has not been updated to use the
"wraps" attribute, which should make refactoring much less ugly:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=wip/v6.9-rc2/unsigned-overflow-sanitizer
[9]
https://lore.kernel.org/all/9162660e-2d6b-47a3-bfa2-77bfc55c817b@paulmck-laptop/
[10] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3201.pdf
--
Kees Cook
s[0] = all_buf + PAGE_SIZE;
if (nr_pages) {
rb->nr_pages = 1;
+ rb->data_pages[0] = all_buf + PAGE_SIZE;
rb->page_order = ilog2(nr_pages);
}
Also, why does rb_alloc() take an "int" nr_pages? The only caller has an
unsigned long argument for nr_pages. Nothing checks for >INT_MAX that I
can find.
--
Kees Cook
which may happen.
Before:
vmlinux.o: warning: objtool: bad call to elf_init_reloc_text_sym() for data
symbol .rodata
After:
vmlinux.o: warning: objtool: .cfi_sites: unexpected reference to non-executable
symbol '.rodata'
Signed-off-by: Kees Cook
---
Cc: Josh Poimboeuf
Cc: Peter Zijl
On Sat, May 04, 2024 at 03:24:02PM -0700, Josh Poimboeuf wrote:
> On Tue, Apr 30, 2024 at 04:51:07PM -0700, Kees Cook wrote:
> > @@ -891,8 +892,8 @@ struct reloc *elf_init_reloc_text_sym(struct elf *elf,
> > struct section *sec,
> > int addend = insn_off;
> &g
corruption indicator that system owners using
warn_limit or panic_on_warn would like to have detected.
Link:
https://lore.kernel.org/lkml/7c41cf3c-2a71-4dbb-8f34-033789090...@gmail.com/ [1]
Suggested-by: Peter Zijlstra
Signed-off-by: Kees Cook
---
Cc: Christian Brauner
Cc: Alexander Viro
Cc: Jens Axboe
site to enforce the immutability of the argument
> through the callbacks prototy.
>
> [...]
Applied to for-next/hardening, thanks!
[1/1] stackleak: don't modify ctl_table argument
https://git.kernel.org/kees/c/0e148d3cca0d
Take care,
--
Kees Cook
dff0091 ("stackleak: Allow runtime disabling of kernel stack
> erasing")
> Cc: sta...@vger.kernel.org
> Acked-by: Kees Cook
> Reviewed-by: Luis Chamberlain
> Signed-off-by: Thomas Weißschuh
> ---
> This was split out of my sysctl-const-handler series [0].
>
&g
On Fri, May 03, 2024 at 03:39:28PM +0200, jvoisin wrote:
> On 4/28/24 19:02, Kees Cook wrote:
> > On Sun, Apr 28, 2024 at 01:02:36PM +0200, jvoisin wrote:
> >> On 4/24/24 23:40, Kees Cook wrote:
> >>> [...]
> >>> While CONFIG_RANDOM_KMALL
site to enforce the immutability of the argument
> through the callbacks prototy.
>
> Fixes: 964c9dff0091 ("stackleak: Allow runtime disabling of kernel stack
> erasing")
> Cc: sta...@vger.kernel.org
I realize I've already Acked, but does this actually need to be CCed
to st
On Mon, Apr 29, 2024 at 08:21:49PM -0700, Joe Perches wrote:
> On Mon, 2024-04-29 at 12:49 -0700, Kees Cook wrote:
> > On Mon, Apr 29, 2024 at 06:39:28PM +, Justin Stitt wrote:
> > > I am going to quote Lee Jones who has been doing some snprintf ->
> &g
On Thu, May 02, 2024 at 11:18:37AM +0200, Peter Zijlstra wrote:
> On Wed, May 01, 2024 at 01:21:42PM -0700, Kees Cook wrote:
> > On Tue, Apr 30, 2024 at 11:15:04AM +0200, Peter Zijlstra wrote:
> > > On Mon, Apr 29, 2024 at 07:40:58PM +0200, Erick Archer wrote:
> > > >
r is not at the end of another structure
> [-Wflex-array-member-not-at-end]
>
> Link: https://github.com/KSPP/linux/issues/202
> Signed-off-by: Gustavo A. R. Silva
Nice! This looks really clean; I'll point people at this patch when they
want to see these kinds of conversions. It has it all! :)
Reviewed-by: Kees Cook
--
Kees Cook
he mentioned results with details of the
> hardware you used for that.
I might be worth looking at the implementation of strscpy(), which is
doing similar multi-byte steps and handles unaligned access.
--
Kees Cook
On Thu, May 02, 2024 at 12:21:28PM +0100, Will Deacon wrote:
> On Wed, Apr 24, 2024 at 12:17:35PM -0700, Kees Cook wrote:
> > Annotate atomic_add_return() and atomic_sub_return() to avoid signed
> > overflow instrumentation. They are expected to wrap around.
> >
> &g
On Fri, Apr 26, 2024 at 08:40:50AM +0100, David Howells wrote:
> Kees Cook wrote:
>
> > - return i + xadd(>counter, i);
> > + return wrapping_add(int, i, xadd(>counter, i));
>
> Ewww. Can't you just mark the variable as wrapping in some way, either by:
&g
On Thu, May 02, 2024 at 12:45:33PM +0300, Andy Shevchenko wrote:
> On Thu, May 2, 2024 at 2:32 AM Kees Cook wrote:
> >
> > Several other "dup"-style interfaces could use the __realloc_size()
> > attribute. (As a reminder to myself and others: "realloc" is
e're copying contents into the
resulting allocation, it must use "realloc_size" to avoid confusing the
compiler's optimization passes.)
Add KUnit test coverage where possible. (KUnit still does not have the
ability to manipulate userspace memory.)
Reviewed-by: Andy Shevchenko
Signed-off-by:
Very effective. :)
Reviewed-by: Kees Cook
--
Kees Cook
e're copying contents into the
resulting allocation, it must use "realloc_size" to avoid confusing the
compiler's optimization passes.)
Add KUnit test coverage where possible. (KUnit still does not have the
ability to manipulate userspace memory.)
Signed-off-by: Kees Cook
---
Cc: An
ds were not affected: __alloc_size continued to work there.
Use a zero-sized allocation instead, which allows __alloc_size to
behave.
Fixes: 4ce615e798a7 ("fortify: Provide KUnit counters for failure testing")
Fixes: fa4a3f86d498 ("fortify: Add KUnit tests for runtime overflows")
> - strcpy(buf, "ttyS0");
> + strscpy(buf, "ttyS0");
> if (!strcmp(str, "ttyb"))
> - strcpy(buf, "ttyS1");
> + strscpy(buf, "ttyS1");
> #endif
> for (s = buf; *s; s++)
> if (isdigit(*s) || *s == ',')
>
> ---
> base-commit: 9e4bc4bcae012c98964c3c2010debfbd9e5b229f
> change-id: 20240429-strncpy-kernel-printk-printk-c-6a72fe6d0715
>
> Best regards,
> --
> Justin Stitt
Yeah, everything here checks out. I had to read through the sysctl
handler pretty carefully, but I think this is a nice readability
improvement. Thanks!
-Kees
--
Kees Cook
o personally I detest struct_size() because I can never remember wtf it
> does, whereas the code it replaces is simple and straight forward :/
Sure, new APIs can involved a learning curve. If we can all handle
container_of(), we can deal with struct_size(). :)
--
Kees Cook
On Wed, May 01, 2024 at 09:33:14AM -0700, Nathan Chancellor wrote:
> On Tue, Apr 30, 2024 at 05:02:22PM -0700, Kees Cook wrote:
> > Since FineIBT performs checking at the destination, it is weaker against
> > attacks that can construct arbitrary executable memory contents. As such,
S (for array indexing) and CONFIG_FORTIFY_SOURCE
> (for strcpy/memcpy-family functions).
>
> Suggested-by: Kees Cook
> Signed-off-by: Erick Archer
Thanks!
Reviewed-by: Kees Cook
--
Kees Cook
Chancellor
Signed-off-by: Kees Cook
---
v3: we don't want to (and can't) turn off FINEIBT
v2: https://lore.kernel.org/lkml/20240430173657.it.699-k...@kernel.org/
v1: https://lore.kernel.org/lkml/20240426222940.work.884-k...@kernel.org/
---
arch/arm64/configs/hardening.config | 1 +
arch/x86
On Wed, May 01, 2024 at 01:06:14PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 30, 2024 at 10:48:36AM -0700, Kees Cook wrote:
> > On Tue, Apr 30, 2024 at 11:21:40AM +0200, Peter Zijlstra wrote:
> > > On Fri, Apr 26, 2024 at 03:29:44PM -0700, Kees Cook wrote:
> > >
&
t;cis_handle = cpu_to_le16(conn->handle);
> aux_num_cis++;
>
> - if (aux_num_cis >= 0x1f)
> + if (aux_num_cis >= cmd->num_cis)
> break;
> }
> cmd->num_cis = aux_num_cis;
Yeah, good idea. No need to repeat a hard-coded value.
Reviewed-by: Kees Cook
--
Kees Cook
viewed-by: Kees Cook
--
Kees Cook
the
newly introduced CONFIG_CFI_AUTO_DEFAULT.
Signed-off-by: Kees Cook
---
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: x...@kernel.org
Cc: "H. Peter Anvin"
Cc: Alexei Starovoitov
Cc: Sami Tolvanen
Cc: Nathan Chancellor
Cc: Josh
An error report from elf_init_reloc_text_sym() doesn't say what list of
symbols it is working on. Include this on the caller's side so it can be
reported when pathological conditions are encountered.
Signed-off-by: Kees Cook
---
I added this to confirm debugging of
https://lore.kernel.org/lkml
-oliver.s...@intel.com
Fixes: 6342a20efbd8 ("objtool: Add elf_create_section_pair()")
Signed-off-by: Kees Cook
---
Cc: Josh Poimboeuf
Cc: Peter Zijlstra
---
drivers/misc/lkdtm/Makefile | 2 +-
drivers/misc/lkdtm/perms.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On Tue, Apr 30, 2024 at 02:15:53PM -0700, Kees Cook wrote:
> On Tue, Apr 30, 2024 at 10:48:36AM -0700, Kees Cook wrote:
> > On Tue, Apr 30, 2024 at 11:21:40AM +0200, Peter Zijlstra wrote:
> > > On Fri, Apr 26, 2024 at 03:29:44PM -0700, Kees Cook wrote:
> > >
> >
On Tue, Apr 30, 2024 at 10:48:36AM -0700, Kees Cook wrote:
> On Tue, Apr 30, 2024 at 11:21:40AM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 26, 2024 at 03:29:44PM -0700, Kees Cook wrote:
> >
> > > - CONFIG_CFI_CLANG=y for x86 and arm64. (And disable FINEIBT since
&g
ariable's type.
The reason not to use the channels[] array is because we're not addressing
anything in the array -- we're addressing past it. Better to use the
correct allocation base.
-Kees
--
Kees Cook
On Tue, Apr 30, 2024 at 11:21:40AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 26, 2024 at 03:29:44PM -0700, Kees Cook wrote:
>
> > - CONFIG_CFI_CLANG=y for x86 and arm64. (And disable FINEIBT since
> > it isn't as secure as straight KCFI.)
>
> Oi ?
Same objection
.)
- CONFIG_PAGE_TABLE_CHECK=y for userspace mapping sanity.
Reviewed-by: Nathan Chancellor
Signed-off-by: Kees Cook
---
v2: move CONFIG_CFI_CLANG=y to global config
v1: https://lore.kernel.org/all/20240426222940.work.884-k...@kernel.org/
---
arch/arm64/configs/hardening.config | 1 +
arch/x86/configs
1 - 100 of 1164 matches
Mail list logo
