Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Tue, 6 Feb 2024 08:16:54 -0800 you wrote:
> 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:
On Thu, 08 Feb 2024, Bart Van Assche wrote:
> On 2/8/24 00:44, Lee Jones wrote:
> > Cc: Andre Hedrick
>
> Please take a look at https://lwn.net/Articles/508222/.
get_maintainer.pl pulled it from here:
https://github.com/torvalds/linux/blob/master/drivers/scsi/3w-.c#L11
I like to involve t
On 2/8/24 00:44, Lee Jones wrote:
Cc: Andre Hedrick
Please take a look at https://lwn.net/Articles/508222/.
Thanks,
Bart.
On Thu, 08 Feb 2024, Petr Mladek wrote:
> On Tue 2024-01-30 15:53:36, Lee Jones wrote:
> > On Tue, 30 Jan 2024, Rasmus Villemoes wrote:
> > > On 30/01/2024 16.07, Lee Jones wrote:
> > > > On Mon, 29 Jan 2024, Lee Jones wrote:
> > > >> On Mon, 29 Jan 2024, David Laight wrote:
> > > snprintf()
On Tue 2024-01-30 15:53:36, Lee Jones wrote:
> On Tue, 30 Jan 2024, Rasmus Villemoes wrote:
> > On 30/01/2024 16.07, Lee Jones wrote:
> > > On Mon, 29 Jan 2024, Lee Jones wrote:
> > >> On Mon, 29 Jan 2024, David Laight wrote:
> > snprintf() does this and has been proven to cause buffer-overflo
On 2/6/24 10:16, Kees Cook wrote:
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: arr
On Tue, Feb 06, 2024 at 08:16:54AM -0800, Kees Cook wrote:
> 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
On Thu, Feb 08, 2024 at 12:12:19PM +0100, Marco Elver wrote:
> git log --grep 'BUG: KFENCE: '
>
> There are more I'm aware of - also plenty I know of in downstream
> kernels (https://arxiv.org/pdf/2311.09394.pdf - Section 5.7).
Good.
> This is a problem shared by all other diagnostic and error r
On Thu, 8 Feb 2024 at 11:55, Borislav Petkov wrote:
>
> On Thu, Feb 08, 2024 at 08:47:37AM +0100, Marco Elver wrote:
> > That's a good question, and I don't have the answer to that - maybe we
> > need to ask Linus then.
>
> Right, before that, lemme put my user hat on.
>
> > We could argue that to
On Thu, 8 Feb 2024 at 10:55, Borislav Petkov wrote:
>
> What about its benefit?
>
> I haven't seen a bug fix saying "found by KFENCE" or so but that doesn't
> mean a whole lot.
It does find some things. You can search for "BUG: KFENCE" on lore,
and there are real bug reports.
That said, there ar
On Thu, Feb 08, 2024 at 08:47:37AM +0100, Marco Elver wrote:
> That's a good question, and I don't have the answer to that - maybe we
> need to ask Linus then.
Right, before that, lemme put my user hat on.
> We could argue that to improve memory safety of the Linux kernel more
> rapidly, enableme
On Thu, 08 Feb 2024, Geert Uytterhoeven wrote:
> Hi Lee,
>
> Thanks for your patch!
>
> On Thu, Feb 8, 2024 at 9:48 AM Lee Jones wrote:
> > There is a general misunderstanding amongst engineers that {v}snprintf()
> > returns the length of the data *actually* encoded into the destination
> > arr
Hi Lee,
Thanks for your patch!
On Thu, Feb 8, 2024 at 9:48 AM Lee Jones wrote:
> There is a general misunderstanding amongst engineers that {v}snprintf()
> returns the length of the data *actually* encoded into the destination
> array. However, as per the C99 standard {v}snprintf() really retur
Commit 94f8f319cbcb ("drm: Remove Kconfig option for legacy support
(CONFIG_DRM_LEGACY)") removes the config DRM_LEGACY, but one reference to
that config is left in the hardening.config fragment.
As there is no drm legacy driver left, we do not need to recommend this
attack surface reduction anymo
Commit 7a628f818499 ("ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL") removes the
config UBSAN_SANITIZE_ALL, but one reference to that config is left in the
hardening.config fragment.
Drop this reference in hardening.config fragment.
Note that CONFIG_UBSAN is still enabled in the hardening.config fragm
Dear Kees,
here are two patches cleaning up the hardening config fragment from obsolete
config options.
Feel free to squash them if you think they should not be two separate commits.
Lukas
Lukas Bulwahn (2):
hardening: drop obsolete UBSAN_SANITIZE_ALL from config fragment
hardening: drop ob
Since snprintf() has the documented, but still rather strange trait of
returning the length of the data that *would have been* written to the
array if space were available, rather than the arguably more useful
length of data *actually* written, it is usually considered wise to use
something else in
Since snprintf() has the documented, but still rather strange trait of
returning the length of the data that *would have been* written to the
array if space were available, rather than the arguably more useful
length of data *actually* written, it is usually considered wise to use
something else in
There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array. However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for
Removing out of need rather than want. I wish to make proper changes to
this file, but my editor is insistent on removing whitespace on save.
Rather than go down the rabbit hole of debugging my editor right now,
I'd rather stay productive. So, out it comes!
EDIT: Found it. Looks like 5a602de997
There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array. However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for
There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array. However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for
Since snprintf() has the documented, but still rather strange trait of
returning the length of the data that *would have been* written to the
array if space were available, rather than the arguably more useful
length of data *actually* written, it is usually considered wise to use
something else in
There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array. However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for
Since 5a602de99797b ("Add .editorconfig file for basic formatting") my
editor has been forced to remove trailing whitespace from any file it
saves. Instead of fighting this recent kernel default, let's start
chipping away at fixing the issues.
Signed-off-by: Lee Jones
---
Cc: Richard Hirst
---
Since 5a602de99797b ("Add .editorconfig file for basic formatting") my
editor has been forced to remove trailing whitespace from any file it
saves. Instead of fighting this recent kernel default, let's start
chipping away at fixing the issues.
Signed-off-by: Lee Jones
---
Cc: Adam Radford
Cc: J
Note: We're also taking the time to obay our new .editorconfig overlord!
For a far better description of the problem than I could author, see
Jon's write-up on LWN [1] and/or Alex's on the Kernel Self Protection
Project [1].
[0] https://lwn.net/Articles/69419/
[1] https://github.com/KSPP/linux/is
27 matches
Mail list logo
