Target tool build against musl fails, because loff_t is undefined,
despite _GNU_SOURCE being defined.
This is because glibc defines loff_t via , but musl defines
loff_t only in fcntl.h and the latter file isn't included beforehand in
imx-usb-loader-target.c.
Add the missing include to and includ
Defining _GNU_SOURCE via userccflags (for target tools) and KBUILD_HOSTCFLAGS
(for host tools) works, but needs to be repeated in subdirectories like i.MX
as well. As we make ample use of the asprintf GNU extension anyway, let's just
define it in the top-level makefile for build of all user code.
Hello Sascha,
On 07.02.25 09:27, Sascha Hauer wrote:
>
> On Wed, 05 Feb 2025 11:25:49 +0100, Jules Maselbas wrote:
>> The include scripts/include/asm-generic/bug.h relied on a printk.h
>> compatible header which is located in the scripts/include/ and was
>> not updated when printk.h was renamed t
On 19.02.25 15:18, Sascha Hauer wrote:
> The pattern malloc(size + constant) is dangerous when size can be
> manipulated by an attacker. In that case 'size' can be manipulated
> in a way that 'size + constant' is 0 due to integer overflow. The
> result is a zero sized buffer to which is then data w
Hi Sascha,
On 19.02.25 15:18, Sascha Hauer wrote:
> The pattern malloc(size + constant) is dangerous when size can be
> manipulated by an attacker. In that case 'size' can be manipulated
> in a way that 'size + constant' is 0 due to integer overflow. The
> result is a zero sized buffer to which is
On 19.02.25 15:18, Sascha Hauer wrote:
> The pattern malloc(size + constant) is dangerous when size can be
> manipulated by an attacker. In that case 'size' can be manipulated
> in a way that 'size + constant' is 0 due to integer overflow. The
> result is a zero sized buffer to which is then data w
On 19.02.25 15:18, Sascha Hauer wrote:
> The pattern malloc(size + constant) is dangerous when size can be
> manipulated by an attacker. In that case 'size' can be manipulated
> in a way that 'size + constant' is 0 due to integer overflow. The
> result is a zero sized buffer to which is then data w
In squashfs_get_link() we have:
int length = min_t(int, i_size_read(inode), PAGE_SIZE);
The inode size is a 64bit number directly read from the device which
is interpreted as a 32bit signed number above. An inode size with the
lower 32bits set to 0x results in length being -1. Lat
On 19.02.25 15:18, Sascha Hauer wrote:
> In squashfs_get_link() we have:
>
> int length = min_t(int, i_size_read(inode), PAGE_SIZE);
>
> The inode size is a 64bit number directly read from the device which
> is interpreted as a 32bit signed number above. An inode size with the
> lower 32bit
On 19.02.25 15:18, Sascha Hauer wrote:
> These are some fixes for memory corruptions that can occur on corrupted
> or manipulated filesystems.
>
> In case you use one of the affected filesystems in a secure boot chain
> you should apply these patches.
>
> Normally you shouldn't use a barebox file
The pattern malloc(size + constant) is dangerous when size can be
manipulated by an attacker. In that case 'size' can be manipulated
in a way that 'size + constant' is 0 due to integer overflow. The
result is a zero sized buffer to which is then data written to.
Avoid this by using struct_size() i
The pattern malloc(size + constant) is dangerous when size can be
manipulated by an attacker. In that case 'size' can be manipulated
in a way that 'size + constant' is 0 due to integer overflow. The
result is a zero sized buffer to which is then data written to.
Avoid this by using size_add() inst
The pattern malloc(size + constant) is dangerous when size can be
manipulated by an attacker. In that case 'size' can be manipulated
in a way that 'size + constant' is 0 due to integer overflow. The
result is a zero sized buffer to which is then data written to.
Avoid this by using size_add() and
The pattern malloc(size + constant) is dangerous when size can be
manipulated by an attacker. In that case 'size' can be manipulated
in a way that 'size + constant' is 0 due to integer overflow. The
result is a zero sized buffer to which is then data written to.
Avoid this by using size_add() inst
These are some fixes for memory corruptions that can occur on corrupted
or manipulated filesystems.
In case you use one of the affected filesystems in a secure boot chain
you should apply these patches.
Normally you shouldn't use a barebox filesystem in a secure boot chain,
but instead use FIT im
On Tue, Feb 18, 2025 at 10:21:35AM +0100, Steffen Trumtrar wrote:
> diff --git a/arch/arm/boards/arrow-axe5-eagle/lowlevel.c
> b/arch/arm/boards/arrow-axe5-eagle/lowlevel.c
> new file mode 100644
> index
> ..b736ca643f86b031dc070baf62f15a4a09e5aaba
> --- /d
On Tue, Feb 18, 2025 at 10:21:34AM +0100, Steffen Trumtrar wrote:
> The Designware XGMAC is designed for 1/2.5/5/10G ethernet applications.
> It is mostly identical to the eqos driver but has a different register
> layout.
>
> Signed-off-by: Steffen Trumtrar
> ---
> drivers/net/Kconfig
On Tue, Feb 18, 2025 at 10:21:32AM +0100, Steffen Trumtrar wrote:
> Add support for the Stratix10 and Agilex5 pll,gate and periph clocks.
>
> Only tested on Agilex5.
>
> Signed-off-by: Steffen Trumtrar
> ---
> drivers/clk/socfpga/Makefile | 4 +-
> drivers/clk/socfpga/clk-agilex5.c
On Tue, Feb 18, 2025 at 10:21:33AM +0100, Steffen Trumtrar wrote:
> The Analog Devices ADIN1300 is a low power 10Mbps,100Mbps, and 1Gbps
> ethernet phy.
> (https://www.analog.com/media/en/technical-documentation/data-sheets/adin1300.pdf)
Where is this driver from? Can you add a reference to the co
On Wed, Feb 19, 2025 at 11:43:29AM +0100, Marco Felsch wrote:
> Hi Sascha,
>
> On 25-02-18, Sascha Hauer wrote:
> > Some i.MX6 configurations use the xload mechanism. With this the ROM
> > only loads and verifies the PBL. The PBL will then load barebox proper.
> > Without verification the barebox
Hi Sascha,
On 25-02-18, Sascha Hauer wrote:
> Some i.MX6 configurations use the xload mechanism. With this the ROM
> only loads and verifies the PBL. The PBL will then load barebox proper.
> Without verification the barebox proper binary is untrusted and could be
> modified. Select PBL_VERIFY_PIGG
21 matches
Mail list logo
