[PATCH v2][next] Bluetooth: hci_conn, hci_sync: Use __counted_by() in multiple structs and avoid -Wfamnae warnings

Prepare 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 at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). A

[PATCH] hardening: Refresh KCFI options, add some more

Add some stuff that got missed along the way: - CONFIG_UNWIND_PATCH_PAC_INTO_SCS=y so SCS vs PAC is hardware selectable. - CONFIG_X86_KERNEL_IBT=y while a default, just be sure. - CONFIG_CFI_CLANG=y for x86 and arm64. (And disable FINEIBT since it isn't as secure as straight KCFI.) - CONFIG

[PATCH][next] Bluetooth: hci_sync, hci_event: Use __counted_by() in multiple structs and avoid -Wfamnae warnings

Prepare 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 at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). A

Re: [PATCH v2] ubsan: Avoid i386 UBSAN handler crashes with Clang

Hi, On Wed, Apr 24, 2024 at 03:40:29PM -0700, Kees Cook wrote: > When generating Runtime Calls, Clang doesn't respect the -mregparm=3 > option used on i386. Hopefully this will be fixed correctly in Clang 19: > https://github.com/llvm/llvm-project/pull/89707 > but we need to fix this for earlier C

Re: [PATCH v4] net: dsa: lan9303: use ethtool_puts() for lan9303_get_strings()

Hello: This patch was applied to netdev/net-next.git (main) by Jakub Kicinski : On Thu, 25 Apr 2024 01:19:13 + you wrote: > This pattern of strncpy with some pointer arithmetic setting fixed-sized > intervals with string literal data is a bit weird so let's use > ethtool_puts() as this has mo

Re: [PATCH v2] ubsan: Avoid i386 UBSAN handler crashes with Clang

On Wed, Apr 24, 2024 at 03:40:29PM -0700, Kees Cook wrote: > When generating Runtime Calls, Clang doesn't respect the -mregparm=3 > option used on i386. Hopefully this will be fixed correctly in Clang 19: > https://github.com/llvm/llvm-project/pull/89707 > but we need to fix this for earlier Clang

Re: [PATCH v2][next] Bluetooth: hci_conn: Use __counted_by() in struct hci_cp_le_big_create_sync and avoid -Wfamnae warning

On Fri, Apr 26, 2024 at 10:45:17AM -0600, Gustavo A. R. Silva wrote: > Prepare 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 at run-time > via CONFIG_UBSAN_BOUNDS (for array

Re: [PATCH] mm/slub: Avoid recursive loop with kmemleak

On Fri, Apr 26, 2024 at 03:52:24PM +0100, Catalin Marinas wrote: > On Thu, Apr 25, 2024 at 01:55:23PM -0700, Kees Cook wrote: > > The system will immediate fill up stack and crash when both Oops, typo from me: "immediately". You'd never guess I'm a native English speaker! :) > > CONFIG_DEBUG_KMEM

[PATCH v2][next] Bluetooth: hci_conn: Use __counted_by() in struct hci_cp_le_big_create_sync and avoid -Wfamnae warning

Prepare 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 at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). A

[PATCH][next] Bluetooth: hci_conn: Use __counted_by() in struct hci_cp_le_big_create_sync and avoid -Wfamnae warning

Prepare 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 at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). A

Re: [PATCH] mm/slub: Avoid recursive loop with kmemleak

On Thu, Apr 25, 2024 at 01:55:23PM -0700, Kees Cook wrote: > The system will immediate fill up stack and crash when both > CONFIG_DEBUG_KMEMLEAK and CONFIG_MEM_ALLOC_PROFILING are enabled. > Avoid allocation tagging of kmemleak caches, otherwise recursive > allocation tracking occurs. > > Fixes: 2

Re: [PATCH] alloc_tag: Tighten file permissions on /proc/allocinfo

On Fri, Apr 26, 2024 at 10:32:27AM +0200, Pavel Machek wrote: > Hi! > > > > > > > The /proc/allocinfo file exposes a tremendous about of information > > > > > > about > > > > > > kernel build details, memory allocations (obviously), and > > > > > > potentially > > > > > > even image layout (due

Re: [PATCH] alloc_tag: Tighten file permissions on /proc/allocinfo

On Fri 2024-04-26 04:25:40, Matthew Wilcox wrote: > On Thu, Apr 25, 2024 at 08:58:34PM -0400, Kent Overstreet wrote: > > On Thu, Apr 25, 2024 at 05:43:33PM -0700, Kees Cook wrote: > > > All this said, I'm still not excited about any of these files living > > > in /proc at all -- we were supposed to

Re: [PATCH] alloc_tag: Tighten file permissions on /proc/allocinfo

Hi! > > > > > The /proc/allocinfo file exposes a tremendous about of information > > > > > about > > > > > kernel build details, memory allocations (obviously), and potentially > > > > > even image layout (due to ordering). As this is intended to be > > > > > consumed > > > > > by system owners

Re: [PATCH 1/4] locking/atomic/x86: Silence intentional wrapping addition

Kees Cook wrote: > - return i + xadd(&v->counter, i); > + return wrapping_add(int, i, xadd(&v->counter, i)); Ewww. Can't you just mark the variable as wrapping in some way, either by: unsigned int __cyclic counter; or, to use rxrpc packet sequence numbers as an example: