Hi,
On Mon, Feb 05, 2024 at 01:37:29AM -0800, Kees Cook wrote:
> In order to mitigate unexpected signed wrap-around[1], bring back the
> signed integer overflow sanitizer. It was removed in commit 6aaa31aeb9cf
> ("ubsan: remove overflow checks") because it was effectively a no-op
> when combined w
Hi,
On Tue, Feb 06, 2024 at 06:22:18AM -0800, Kees Cook wrote:
> Similar to strscpy(), update strscpy_pad()'s 3rd argument to be
> optional when the destination is a compile-time known size array.
This patch is diff'd against Patch 1/4 in this series, right? I wonder
why you split them up. If I h
Hi,
On Tue, Feb 06, 2024 at 06:22:16AM -0800, Kees Cook wrote:
> In preparation for making strscpy_pad()'s 3rd argument optional, redefine
> it as a macro. This also has the benefit of allowing greater FORITFY
> introspection, as it couldn't see into the strscpy() nor the memset()
> within strscpy
On 2/6/24 12:39, Kees Cook wrote:
struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated
as a flexible array, so convert it into one so that it doesn't trip the
array bounds sanitizer[1]. Only once place was using sizeof() on the
whole struct (in 11n.c), so adjust it to follow
On Mon, Jan 22, 2024 at 04:27:45PM -0800, Kees Cook wrote:
> In an effort to separate intentional arithmetic wrap-around from
> unexpected wrap-around, we need to refactor places that depend on this
> kind of math. One of the most common code patterns of this is:
>
> VAR + value < VAR
>
> N
struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated
as a flexible array, so convert it into one so that it doesn't trip the
array bounds sanitizer[1]. Only once place was using sizeof() on the
whole struct (in 11n.c), so adjust it to follow the calculation pattern
used by scan.c
Apologies -- this patch is incomplete. My "git add" failed me. ;) I'll
send a v2!
-Kees
On Tue, Feb 06, 2024 at 08:35:04AM -0800, Kees Cook wrote:
> struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated
> as a flexible array, so convert it into one so that it doesn't trip the
>
On 2/6/24 11:03, Kees Cook wrote:
Without changing the structure size (since it is UAPI), add a proper
flexible array member, and reference it in the kernel so that it will
not be trip the array-bounds sanitizer[1].
Link: https://github.com/KSPP/linux/issues/113 [1]
Cc: Juergen Gross
Cc: Ste
Without changing the structure size (since it is UAPI), add a proper
flexible array member, and reference it in the kernel so that it will
not be trip the array-bounds sanitizer[1].
Link: https://github.com/KSPP/linux/issues/113 [1]
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Oleksandr Tyshchen
On 2/6/24 04:31, Kees Cook wrote:
Provide helpers that will perform wrapping addition, subtraction, or
multiplication without tripping the arithmetic wrap-around sanitizers. The
first argument is the type under which the wrap-around should happen
with. In other words, these two calls will get
On 2/6/24 04:31, Kees Cook wrote:
The check_*_overflow() helpers will return results with potentially
wrapped-around values. These values have always been checked by the
selftests, so avoid the confusing language in the kern-doc. The idea of
"safe for use" was relative to the expectation of wh
struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated
as a flexible array, so convert it into one so that it doesn't trip the
array bounds sanitizer[1]. The code was already calculating sizes by not
including the trailing single element, so no sizeof() change are needed.
Link: ht
Since NUM_XMIT_BUFFS is always 1, building m68k with sun3_defconfig and
-Warraybounds, this build warning is visible[1]:
drivers/net/ethernet/i825xx/sun3_82586.c: In function 'sun3_82586_timeout':
drivers/net/ethernet/i825xx/sun3_82586.c:990:122: warning: array subscript 1 is
above array bounds o
Add device-tree for LG Optimus Vu P895, which is a NVIDIA
Tegra30-based smartphone, originally running Android.
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/boot/dts/nvidia/Makefile|1 +
arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 496 +
arch/arm/boot/dts/nvidia/tegra30-l
Add device-tree for LG Optimus 4X HD P880, which is a NVIDIA
Tegra30-based smartphone, originally running Android.
Signed-off-by: Svyatoslav Ryhel
---
arch/arm/boot/dts/nvidia/Makefile| 1 +
arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 489 +++
2 files changed, 49
From: Maxim Schwalm
Add a compatible for the LG Optimus Vu P895 and Optimus 4X P880.
Signed-off-by: Maxim Schwalm
Signed-off-by: Svyatoslav Ryhel
Acked-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/arm/tegra.yaml | 8
1 file changed, 8 insertions(+)
diff --git a/Doc
Bring up Tegra 3 based LG phones Optimus 4X HD and Optimus Vu based
on LG X3 board.
---
Changes from v2:
- switched from _ to - in node names
Changes from v1:
- switched from prefix lge to lg
---
Maxim Schwalm (1):
dt-bindings: arm: tegra: Add LG Optimus Vu P895 and Optimus 4X P880
Svyatoslav
On Tue, Feb 6, 2024 at 4:22 PM Kees Cook wrote:
>
> The ARCH=um build has its own idea about strscpy()'s definition. Adjust
> the callers to remove the redundant sizeof() arguments ahead of treewide
> changes, since it needs a manual adjustment for the newly named
> sized_strscpy() export.
...
>
Using sizeof(dst) for the "size" argument in strscpy() is the
overwhelmingly common case. Instead of requiring this everywhere, allow a
2-argument version to be used that will use the sizeof() internally. There
are other functions in the kernel with optional arguments[1], so this
isn't unprecedente
The ARCH=um build has its own idea about strscpy()'s definition. Adjust
the callers to remove the redundant sizeof() arguments ahead of treewide
changes, since it needs a manual adjustment for the newly named
sized_strscpy() export.
Cc: Richard Weinberger
Cc: linux...@lists.infradead.org
Signed-o
Similar to strscpy(), update strscpy_pad()'s 3rd argument to be
optional when the destination is a compile-time known size array.
Cc: Andy Shevchenko
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Kees Cook
---
include/linux/string.h | 29 ++---
1 file changed, 18 in
In preparation for making strscpy_pad()'s 3rd argument optional, redefine
it as a macro. This also has the benefit of allowing greater FORITFY
introspection, as it couldn't see into the strscpy() nor the memset()
within strscpy_pad().
Cc: Andy Shevchenko
Cc: linux-hardening@vger.kernel.org
Signed
v3:
- add missed args.h include (andy)
v2: https://lore.kernel.org/all/20240205122916.it.909-k...@kernel.org/
v1: https://lore.kernel.org/all/20240131055340.work.279-k...@kernel.org/
Hi,
Make it possible for strscpy() and strscpy_pad() to use 2 arguments,
making "sizeof(dst)" be the the default
On Mon, Feb 05, 2024 at 02:10:26PM +0100, Marco Elver wrote:
> On Mon, 5 Feb 2024 at 13:59, Kees Cook wrote:
> >
> > On Mon, Feb 05, 2024 at 01:54:24PM +0100, Andrey Ryabinin wrote:
> > >
> > >
> > > On 2/5/24 10:37, Kees Cook wrote:
> > >
> > > > ---
> > > > include/linux/compiler_types.h | 9 +
This allows replacements of the idioms "var += offset" and "var -= offset"
with the wrapping_inc() and wrapping_dec() helpers respectively. They
will avoid wrap-around sanitizer instrumentation.
Add to the selftests to validate behavior and lack of side-effects.
Cc: Rasmus Villemoes
Cc: Marco El
v4:
- use __builtin directly (marco)
- rename to wrapping_* (eric)
- update kern-doc (rasmus)
v3: https://lore.kernel.org/all/20240205090854.make.507-k...@kernel.org/
v2: https://lore.kernel.org/all/20240130220218.it.154-k...@kernel.org/
v1: https://lore.kernel.org/lkml/20240129182845.work.694-k
The check_*_overflow() helpers will return results with potentially
wrapped-around values. These values have always been checked by the
selftests, so avoid the confusing language in the kern-doc. The idea of
"safe for use" was relative to the expectation of whether or not the
caller wants a wrapped
Provide helpers that will perform wrapping addition, subtraction, or
multiplication without tripping the arithmetic wrap-around sanitizers. The
first argument is the type under which the wrap-around should happen
with. In other words, these two calls will get very different results:
wrappi
On Mon, Feb 05, 2024 at 02:31:04PM +0100, Marco Elver wrote:
> On Mon, 5 Feb 2024 at 10:12, Kees Cook wrote:
> >
> > Provide helpers that will perform wrapping addition, subtraction, or
> > multiplication without tripping the arithmetic wrap-around sanitizers. The
> > first argument is the type un
On Tue, Feb 06, 2024 at 09:42:26AM +0100, Rasmus Villemoes wrote:
> On 06/02/2024 00.21, Kees Cook wrote:
> >
> >
> > On February 5, 2024 11:17:12 PM GMT, Eric Biggers
> > wrote:
> >> On Mon, Feb 05, 2024 at 02:44:14PM -0800, Kees Cook wrote:
> >>> On Mon, Feb 05, 2024 at 12:21:45PM -0800, Eric
On 06/02/2024 00.21, Kees Cook wrote:
>
>
> On February 5, 2024 11:17:12 PM GMT, Eric Biggers wrote:
>> On Mon, Feb 05, 2024 at 02:44:14PM -0800, Kees Cook wrote:
>>> On Mon, Feb 05, 2024 at 12:21:45PM -0800, Eric Biggers wrote:
On Mon, Feb 05, 2024 at 01:12:30AM -0800, Kees Cook wrote:
>>>
31 matches
Mail list logo
