On Thu, 2023-11-30 at 17:25 -0800, Jakub Kicinski wrote:
> On Thu, 30 Nov 2023 12:01:01 -0800 Kees Cook wrote:
> > This has the additional benefit of being defensive in the face of nlattr
> > corruption or logic errors (i.e. nla_len being set smaller than
> > NLA_HDRLEN).
>
> As Johannes predicted
On Thu, 30 Nov 2023 14:00:33 -0800 Kees Cook wrote:
> Applied to for-next/hardening, thanks!
>
> [1/1] net: mdio: replace deprecated strncpy with strscpy
> https://git.kernel.org/kees/c/3247bb945786
newer version of this was posted...
On Thu, 30 Nov 2023 14:00:28 -0800 Kees Cook wrote:
> [1/1] qlcnic: replace deprecated strncpy with strscpy
> https://git.kernel.org/kees/c/f8bef1ef8095
You asked for changes yourself here, please drop all the networking
patches you applied today :|
On Thu, 30 Nov 2023 13:59:48 -0800 Kees Cook wrote:
> [1/1] net: ena: replace deprecated strncpy with strscpy
> https://git.kernel.org/kees/c/111f5a435d33
Again, please drop, Arthur requested for the commit message
to be changed.
On Thu, 30 Nov 2023 13:59:58 -0800 Kees Cook wrote:
> Applied to for-next/hardening, thanks!
>
> [1/1] net: dsa: lan9303: use ethtool_sprintf() for lan9303_get_strings()
> https://git.kernel.org/kees/c/f1c7720549bf
Please drop this, it got changes requested on our end because
I figured Alex
On Thu, 30 Nov 2023 12:56:08 -0800
Kees Cook wrote:
> strlcpy() reads the entire source buffer first. This read may exceed
> the destination size limit. This is both inefficient and can lead
> to linear read overflows if a source string is not NUL-terminated[1].
> Additionally, it returns the siz
On Thu, 30 Nov 2023 12:56:08 -0800
Kees Cook wrote:
> strlcpy() reads the entire source buffer first. This read may exceed
> the destination size limit. This is both inefficient and can lead
> to linear read overflows if a source string is not NUL-terminated[1].
> Additionally, it returns the siz
On Thu, 30 Nov 2023 12:01:01 -0800 Kees Cook wrote:
> This has the additional benefit of being defensive in the face of nlattr
> corruption or logic errors (i.e. nla_len being set smaller than
> NLA_HDRLEN).
As Johannes predicted I'd rather not :(
The callers should put the nlattr thru nla_ok() d
On Wed, 2023-11-29 at 15:07 -0600, Madhavan T. Venkataraman wrote:
> Threat Model
>
>
> In the threat model in Heki, the attacker is a user space attacker
> who exploits
> a kernel vulnerability to gain more privileges or bypass the kernel's
> access
> control and self-protection mech
On Thu, 19 Oct 2023 21:34:35 +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> Let's instead use strscpy() [2] as it guarantees NUL-termination on the
> desti
On Thu, 19 Oct 2023 17:54:15 +, Justin Stitt wrote:
> Found with grep.
>
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> We expect super->signature to be NUL-terminated based on
On Wed, 18 Oct 2023 22:48:49 +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> We expect both data->subsysnqn and data->hostnqn to be NUL-terminated
> based o
On Thu, 12 Oct 2023 19:44:29 +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> We expect fw_info->fw_file_name to be NUL-terminated based on its use
> within
On Thu, 12 Oct 2023 21:43:02 +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> We expect new_bus->id to be NUL-terminated but not NUL-padded based on
> its pr
On Sat, 07 Oct 2023 16:32:34 +0200, Christophe JAILLET 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 checking via CONFIG_UBSAN_BOUNDS
> (for arr
On Tue, 10 Oct 2023 06:59:44 -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 index
On Thu, 05 Oct 2023 18:56:50 +, Justin Stitt 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_sprintf() as this has more obvious behavior and is less-error
> prone.
>
> Nicely, we also g
On Thu, 05 Oct 2023 00:56:08 +, Justin Stitt wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> NUL-padding is not necessary as host_info is initialized to
> `ena_dev->host_at
On Tue, 03 Oct 2023 16:18:38 -0700, 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
> their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for
> array indexing) and C
On Tue, 03 Oct 2023 21:01:58 +, Justin Stitt wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> A suitable replacement is `strscpy` [2] due to the fact that it
> guarantees NU
On 11/30/23 15:07, Kees Cook wrote:
On Thu, Nov 30, 2023 at 02:52:10PM -0600, Gustavo A. R. Silva wrote:
-Wstringop-overflow is buggy in GCC-11. Therefore, we should disable
Can you add some links for this? For example, maybe this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490
Or disc
On Thu, Oct 19, 2023 at 05:44:59PM +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> Based on the deliberate `sizeof(dest) ... - 1` pattern we can see that
>
On Mon, Oct 30, 2023 at 09:43:20PM +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> We don't need the NUL-padding behavior that strncpy() provides as vscsi
>
On Mon, Oct 30, 2023 at 08:40:48PM +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> We expect partition_name to be NUL-terminated based on its usage with
> f
On Mon, Oct 30, 2023 at 07:04:33PM +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> We expect these fields to be NUL-terminated as the property names from
>
On Thu, Nov 30, 2023 at 02:52:10PM -0600, Gustavo A. R. Silva wrote:
> -Wstringop-overflow is buggy in GCC-11. Therefore, we should disable
Can you add some links for this? For example, maybe this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490
Or discussions from -next builds?
> this option
On Thu, Nov 30, 2023 at 09:38:11PM +0100, Christophe JAILLET wrote:
> Le 30/11/2023 à 21:12, Kees Cook a écrit :
> [...]
> > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
> > index 8c0e5442597e..183f353b3852 100644
> > --- a/fs/kernfs/dir.c
> > +++ b/fs/kernfs/dir.c
> [...]
> > @@ -158,18 +159,22
strlcpy() reads the entire source buffer first. This read may exceed
the destination size limit. This is both inefficient and can lead
to linear read overflows if a source string is not NUL-terminated[1].
Additionally, it returns the size of the source string, not the
resulting size of the destinat
-Wstringop-overflow is buggy in GCC-11. Therefore, we should disable
this option specifically for that compiler version. To achieve this,
we introduce a new configuration option: GCC11_NO_STRINGOP_OVERFLOW.
The compiler option related to string operation overflow is now managed
under configuration
Both dir.c and namei.c need to perform the same work to figure out a
directory entry's name and size. Extract this into a helper for use
in the next patch.
Cc: Anders Larsen
Link: https://lore.kernel.org/r/20231118033225.2181299-1-keesc...@chromium.org
Signed-off-by: Kees Cook
---
fs/qnx4/dir.c
Use the new common directory entry name accessor helper to avoid
confusing the compiler about over-running the file name buffer. Avoids
false positive buffer overflow warning:
[ 4849.636861] detected buffer overflow in strlen
[ 4849.636897] [ cut here ]
[ 4849.636902] kerne
Hi,
This attempts to fix the issue Ronald Monthero found[1]. Avoids using a
too-short struct buffer when reading the string, by using the existing
struct union.
-Kees
[1]
https://lore.kernel.org/lkml/20231112095353.579855-1-debug.pengui...@gmail.com/
v2:
- Use BUILD_BUG_ON() instead of _Stati
On Thu, 16 Nov 2023 11:15:10 -0800, Kees Cook wrote:
> strlcpy() reads the entire source buffer first. This read may exceed
> the destination size limit. This is both inefficient and can lead
> to linear read overflows if a source string is not NUL-terminated[1].
> Additionally, it returns the size
On Tue, 14 Nov 2023 09:54:18 -0800, Kees Cook wrote:
> strlcpy() reads the entire source buffer first. This read may exceed
> the destination size limit. This is both inefficient and can lead
> to linear read overflows if a source string is not NUL-terminated[1].
> Additionally, it returns the size
strlcpy() reads the entire source buffer first. This read may exceed
the destination size limit. This is both inefficient and can lead
to linear read overflows if a source string is not NUL-terminated[1].
Additionally, it returns the size of the source string, not the
resulting size of the destinat
Le 30/11/2023 à 21:12, Kees Cook a écrit :
One of the last remaining users of strlcpy() in the kernel is
kernfs_path_from_node_locked(), which passes back the problematic "length
we _would_ have copied" return value to indicate truncation. Convert the
chain of all callers to use the negative ret
On 11/30/23 12:11, Gustavo A. R. Silva wrote:
On 11/30/23 14:02, Kees Cook wrote:
Without visibility into the initializers for data->innr, GCC suspects
using it as an index could walk off the end of the various 14-element
arrays in data. Perform an explicit clamp to the array size. Silences
th
One of the last remaining users of strlcpy() in the kernel is
kernfs_path_from_node_locked(), which passes back the problematic "length
we _would_ have copied" return value to indicate truncation. Convert the
chain of all callers to use the negative return value (some of which
already doing this e
strlcpy() reads the entire source buffer first. This read may exceed
the destination size limit. This is both inefficient and can lead
to linear read overflows if a source string is not NUL-terminated[1].
Additionally, it returns the size of the source string, not the
resulting size of the destinat
strlcpy() reads the entire source buffer first. This read may exceed
the destination size limit. This is both inefficient and can lead
to linear read overflows if a source string is not NUL-terminated[1].
Additionally, it returns the size of the source string, not the
resulting size of the destinat
Hi,
One of the last users of strlcpy() is kernfs, which has some complex
calling hierarchies that needed to be carefully examined. This series
refactors the strlcpy() calls into strscpy() calls, and bubbles up all
changes in return value checking for callers. Future work in kernfs and
sysfs will s
On 11/30/23 14:02, Kees Cook wrote:
Without visibility into the initializers for data->innr, GCC suspects
using it as an index could walk off the end of the various 14-element
arrays in data. Perform an explicit clamp to the array size. Silences
the following warning with GCC 12+:
../drivers/
On 11/30/23 14:01, Kees Cook wrote:
The return value from nla_len() is never expected to be negative, and can
never be more than struct nlattr::nla_len (a u16). Adjust the prototype
on the function, and explicitly bounds check the subtraction. This will
let GCC's value range optimization passe
Without visibility into the initializers for data->innr, GCC suspects
using it as an index could walk off the end of the various 14-element
arrays in data. Perform an explicit clamp to the array size. Silences
the following warning with GCC 12+:
../drivers/hwmon/pc87360.c: In function 'pc87360_upd
The return value from nla_len() is never expected to be negative, and can
never be more than struct nlattr::nla_len (a u16). Adjust the prototype
on the function, and explicitly bounds check the subtraction. This will
let GCC's value range optimization passes know that the return can never
be negat
On Thu, Nov 30, 2023 at 2:10 AM Jason Gunthorpe wrote:
>
> iort_iommu_get_resv_regions() needs access to the parsed id array that is
> currently stored in the iommu_fwspec.
>
> Instead of getting this from the fwspec inside the iort code have the
> caller pass it in.
>
> Signed-off-by: Jason Gunth
On Thu, Nov 30, 2023 at 2:11 AM Jason Gunthorpe wrote:
>
> Similar to of_iommu_for_each_id() this parses the VIOT ACPI description
> and invokes a function over each entry in the table.
>
> Have viot_iommu_configure() use the new function to call
> viot_dev_iommu_init().
>
> Signed-off-by: Jason G
On Thu, Nov 30, 2023 at 2:11 AM Jason Gunthorpe wrote:
>
> Similar to of_iommu_for_each_id() this parses the IORT ACPI description
> and invokes a function over each entry in the table.
>
> Have iort_iommu_configure_id() use the new function to call
> iort_iommu_xlate().
>
> Signed-off-by: Jason G
On Wed, Nov 29, 2023 at 03:07:15PM -0600, Madhavan T. Venkataraman wrote:
> Kernel Lockdown
> ---
>
> But, we must provide at least some security in V2. Otherwise, it is useless.
>
> So, we have implemented what we call a kernel lockdown. At the end of kernel
> boot, Heki establishes
49 matches
Mail list logo
