"Gustavo A. R. Silva" wrote:
> Fix boot crash on Raspberry Pi by moving the update to `event->datalen`
> before data is copied into flexible-array member `data` via `memcpy()`.
>
> Flexible-array member `data` was annotated with `__counted_by(datalen)`
> in commit 62d19b358088 ("wifi: brcmfmac:
Hi Nathan,
On 2/27/24 00:54, Nathan Chancellor wrote:
When booting a CONFIG_FORTIFY_SOURCE=y kernel compiled with a toolchain
that supports __counted_by() (such as clang-18 and newer), there is a
panic on boot:
[2.913770] memcpy: detected buffer overflow: 72 byte write of buffer
size 0
On 27/02/2024 01:54, Nathan Chancellor wrote:
When booting a CONFIG_FORTIFY_SOURCE=y kernel compiled with a toolchain
that supports __counted_by() (such as clang-18 and newer), there is a
panic on boot:
[2.913770] memcpy: detected buffer overflow: 72 byte write of buffer
size 0
[2
Because sandboxing can be used as an opportunistic security measure,
user space may not log unsupported features. Let the system
administrator know if an application tries to use Landlock but failed
because it isn't enabled at boot time. This may be caused by bootloader
configurations with outdat
On Tue, Feb 27, 2024 at 3:08 AM Kees Cook wrote:
>
> On Mon, Feb 26, 2024 at 05:54:58PM -0700, Nathan Chancellor wrote:
> > When booting a CONFIG_FORTIFY_SOURCE=y kernel compiled with a toolchain
> > that supports __counted_by() (such as clang-18 and newer), there is a
> > panic on boot:
> >
> >
On Tue, Feb 27, 2024 at 11:14 AM Daniel Lezcano
wrote:
>
> On 27/02/2024 01:54, Nathan Chancellor wrote:
> > When booting a CONFIG_FORTIFY_SOURCE=y kernel compiled with a toolchain
> > that supports __counted_by() (such as clang-18 and newer), there is a
> > panic on boot:
> >
> >[2.913770
On 2/27/2024 10:19 AM, Kalle Valo wrote:
"Gustavo A. R. Silva" wrote:
Fix boot crash on Raspberry Pi by moving the update to `event->datalen`
before data is copied into flexible-array member `data` via `memcpy()`.
Flexible-array member `data` was annotated with `__counted_by(datalen)`
in comm
Extend the kernel support section with one subsection for build time
configuration and another for boot time configuration.
Extend the boot time subsection with a concrete example.
Update the journalctl command to include the boot option.
Cc: Günther Noack
Cc: Kees Cook
Signed-off-by: Mickaël
On Tue, 27 Feb 2024 01:24:41 +0530, Raihan Ahamed wrote:
> Document the compatible for the MSM8953-based Lenovo P2 smartphone released
> in 2016.
>
> Acked-by: Krzysztof Kozlowski
> Signed-off-by: Raihan Ahamed
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> 1 file changed,
"Gustavo A. R. Silva" wrote:
> Fix boot crash on Raspberry Pi by moving the update to `event->datalen`
> before data is copied into flexible-array member `data` via `memcpy()`.
>
> Flexible-array member `data` was annotated with `__counted_by(datalen)`
> in commit 62d19b358088 ("wifi: brcmfmac:
On Sat, Feb 17, 2024 at 03:18:59PM -0600, Alex Elder wrote:
> On 2/17/24 9:47 AM, Erick Archer wrote:
> > When a struct containing a flexible array is included in another struct,
> > and there is a member after the struct-with-flex-array, there is a
> > possibility of memory overlap. These cases mu
On 27/02/2024 12:09, Rafael J. Wysocki wrote:
On Tue, Feb 27, 2024 at 11:14 AM Daniel Lezcano
wrote:
On 27/02/2024 01:54, Nathan Chancellor wrote:
When booting a CONFIG_FORTIFY_SOURCE=y kernel compiled with a toolchain
that supports __counted_by() (such as clang-18 and newer), there is a
pani
On 22.02.24 18:18, Kees Cook wrote:
When building with CONFIG_XEN_PV=y, .text symbols are emitted into the
.notes section so that Xen can find the "startup_xen" entry point. This
information is used prior to booting the kernel, so relocations are not
useful. In fact, performing relocations agains
On Tue, Feb 27, 2024 at 04:37:36PM +0100, Daniel Lezcano wrote:
> On 27/02/2024 12:09, Rafael J. Wysocki wrote:
> > On Tue, Feb 27, 2024 at 11:14 AM Daniel Lezcano
> > wrote:
> > >
> > > On 27/02/2024 01:54, Nathan Chancellor wrote:
> > > > When booting a CONFIG_FORTIFY_SOURCE=y kernel compiled w
Hi Daniel and Lukasz,
On Tue, Feb 27, 2024 at 04:37:36PM +0100, Daniel Lezcano wrote:
> On 27/02/2024 12:09, Rafael J. Wysocki wrote:
> > On Tue, Feb 27, 2024 at 11:14 AM Daniel Lezcano
> > wrote:
> > >
> > > On 27/02/2024 01:54, Nathan Chancellor wrote:
> > > > When booting a CONFIG_FORTIFY_SOU
On Tue, Feb 27, 2024 at 12:05:49PM +0100, Mickaël Salaün wrote:
> Extend the kernel support section with one subsection for build time
> configuration and another for boot time configuration.
>
> Extend the boot time subsection with a concrete example.
>
> Update the journalctl command to include
On February 27, 2024 8:13:35 AM PST, "Jürgen Groß" wrote:
>On 22.02.24 18:18, Kees Cook wrote:
>> When building with CONFIG_XEN_PV=y, .text symbols are emitted into the
>> .notes section so that Xen can find the "startup_xen" entry point. This
>> information is used prior to booting the kernel, so
On 27/02/2024 17:26, Kees Cook wrote:
On Tue, Feb 27, 2024 at 04:37:36PM +0100, Daniel Lezcano wrote:
On 27/02/2024 12:09, Rafael J. Wysocki wrote:
On Tue, Feb 27, 2024 at 11:14 AM Daniel Lezcano
wrote:
On 27/02/2024 01:54, Nathan Chancellor wrote:
When booting a CONFIG_FORTIFY_SOURCE=y ker
On Tue, Feb 27, 2024 at 05:47:44PM +0100, Daniel Lezcano wrote:
> Ok my misunderstanding was I thought sizeof() was calling _bdos under the
> hood, so when calling sizeof(flex_array), it was returning the computed size
> inferring from the __counted_by field.
Yeah, sizeof() has a very limited scop
On Tue, Feb 27, 2024 at 05:13:35PM +0100, Jürgen Groß wrote:
> ... a test of "sec_applies->shdr.sh_type == SHT_NOTE" work as well?
Oh yeah! Thanks. I'll send a v2.
--
Kees Cook
When building with CONFIG_XEN_PV=y, .text symbols are emitted into
the .notes section so that Xen can find the "startup_xen" entry point.
This information is used prior to booting the kernel, so relocations
are not useful. In fact, performing relocations against the .notes
section means that the KA
For reasons I cannot understand, m68k moves the start of the stack frame
for consecutive calls to the same function if the function's test
variable is larger than 8 bytes. This was only happening for the char
array test (obviously), so adjust the length of the string for m68k
only. I want the array
On Feb 27 2024, Kees Cook wrote:
> For reasons I cannot understand, m68k moves the start of the stack frame
> for consecutive calls to the same function
It's called optimisation.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"A
On Tue, Feb 27, 2024 at 02:46:56PM -0800, Kees Cook wrote:
> For reasons I cannot understand, m68k moves the start of the stack frame
> for consecutive calls to the same function if the function's test
> variable is larger than 8 bytes. This was only happening for the char
> array test (obviously),
Hi,
On Mon, Jan 8, 2024 at 4:54 PM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Dec 7, 2023 at 5:03 PM Douglas Anderson wrote:
> >
> > When testing hard lockup handling on my sc7180-trogdor-lazor device
> > with pseudo-NMI enabled, with serial console enabled and with kgdb
> > disabled, I found that
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Sat, 24 Feb 2024 19:19:32 +0100 you wrote:
> This is an effort to get rid of all multiplications from allocation
> functions in order to prevent integer overflows [1][2].
>
> As the "port_prox" variable is a point
Hi Kees,
On Tue, Feb 27, 2024 at 11:47 PM Kees Cook wrote:
> For reasons I cannot understand, m68k moves the start of the stack frame
> for consecutive calls to the same function if the function's test
> variable is larger than 8 bytes. This was only happening for the char
> array test (obviously
27 matches
Mail list logo
