[PATCH 0/5] Filesystem memory corruption fixes

[PATCH 0/5] Filesystem memory corruption fixes

[Sascha Hauer]

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 images on a raw partition. We never made this explicit
though. Ahmad has done this recently:

https://lore.kernel.org/barebox/20250217180949.3961860-3-a.fatoum@pengutronix.de/T/#u

I digged through the U-Boot code and there are a few CVE fixes in the
ext4 code that we'll likely need as well. But even with these applied
we don't consider the barebox filesystems as suitable for secure boot.

For those curious we consider adding support for dm-verity at some
point. This would allow us to remove the attack surface from the
filesystem implementations and we could also use bootspec rather than
signed FIT images.

Sascha

Sascha Hauer (5):
  CVE-2025-26722: fs: squashfs: Ensure positive inode length
  CVE-2025-26724: fs: cramfs: fix malloc(size + constant) buffer
    overflow issues
  CVE-2025-26723: fs: ext4: fix malloc(size + constant) buffer overflow
    issues
  CVE-2025-26725: fs: jffs2: fix malloc(size + constant) buffer overflow
    issues
  CVE-2025-26721: fs: pstore: fix malloc(size + constant) buffer
    overflow issues

 fs/cramfs/cramfs.c    | 2 +-
 fs/ext4/ext_barebox.c | 2 +-
 fs/jffs2/malloc.c     | 4 ++--
 fs/jffs2/nodelist.h   | 2 +-
 fs/jffs2/readinode.c  | 2 +-
 fs/pstore/fs.c        | 2 +-
 fs/squashfs/symlink.c | 8 ++++++--
 7 files changed, 13 insertions(+), 9 deletions(-)

-- 
2.39.5

[PATCH 1/5] CVE-2025-26722: fs: squashfs: Ensure positive inode length

[Sascha Hauer]

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 0xffffffff results in length being -1. Later we
do a:

	symlink = malloc(length + 1);

With length being -1 this results in allocating a zero size buffer which
is then overwritten by following code.

Fix this by first making sure that the inode length is positive.
Afterwards limit the length to the desired range, explicitly using
loff_t as the type to compare to make sure we do not truncate the
original data type during comparison.

Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 fs/squashfs/symlink.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/squashfs/symlink.c b/fs/squashfs/symlink.c
index 40b9bdcc8b..cb14eb20a5 100644
--- a/fs/squashfs/symlink.c
+++ b/fs/squashfs/symlink.c
@@ -43,16 +43,20 @@
 static const char *squashfs_get_link(struct dentry *dentry, struct inode *inode)
 {
 	struct super_block *sb = inode->i_sb;
-	int index = 0;
 	u64 block = squashfs_i(inode)->start;
 	int offset = squashfs_i(inode)->offset;
-	int length = min_t(int, i_size_read(inode) - index, PAGE_SIZE);
+	size_t length;
 	int bytes;
 	unsigned char *symlink;
 
 	TRACE("Entered squashfs_symlink_readpage, start block "
 			"%llx, offset %x\n", block, offset);
 
+	if (i_size_read(inode) < 0)
+		return NULL;
+
+	length = min_t(loff_t, i_size_read(inode), PAGE_SIZE);
+
 	symlink = malloc(length + 1);
 	if (!symlink)
 		return NULL;
-- 
2.39.5

Re: [PATCH 1/5] CVE-2025-26722: fs: squashfs: Ensure positive inode length

[Ahmad Fatoum]

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 32bits set to 0xffffffff results in length being -1. Later we
> do a:
> 
> 	symlink = malloc(length + 1);
> 
> With length being -1 this results in allocating a zero size buffer which
> is then overwritten by following code.
> 
> Fix this by first making sure that the inode length is positive.
> Afterwards limit the length to the desired range, explicitly using
> loff_t as the type to compare to make sure we do not truncate the
> original data type during comparison.
> 
> Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>

> ---
>  fs/squashfs/symlink.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/squashfs/symlink.c b/fs/squashfs/symlink.c
> index 40b9bdcc8b..cb14eb20a5 100644
> --- a/fs/squashfs/symlink.c
> +++ b/fs/squashfs/symlink.c
> @@ -43,16 +43,20 @@
>  static const char *squashfs_get_link(struct dentry *dentry, struct inode *inode)
>  {
>  	struct super_block *sb = inode->i_sb;
> -	int index = 0;
>  	u64 block = squashfs_i(inode)->start;
>  	int offset = squashfs_i(inode)->offset;
> -	int length = min_t(int, i_size_read(inode) - index, PAGE_SIZE);
> +	size_t length;
>  	int bytes;
>  	unsigned char *symlink;
>  
>  	TRACE("Entered squashfs_symlink_readpage, start block "
>  			"%llx, offset %x\n", block, offset);
>  
> +	if (i_size_read(inode) < 0)
> +		return NULL;
> +
> +	length = min_t(loff_t, i_size_read(inode), PAGE_SIZE);
> +
>  	symlink = malloc(length + 1);
>  	if (!symlink)
>  		return NULL;


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 2/5] CVE-2025-26724: fs: cramfs: fix malloc(size + constant) buffer overflow issues

[Sascha Hauer]

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() instead.

Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 fs/cramfs/cramfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/cramfs/cramfs.c b/fs/cramfs/cramfs.c
index e554ebef6f..641a6d2b05 100644
--- a/fs/cramfs/cramfs.c
+++ b/fs/cramfs/cramfs.c
@@ -423,7 +423,7 @@ static const char *cramfs_get_link(struct dentry *dentry, struct inode *inode)
 {
 	int ret;
 
-	inode->i_link = xzalloc(inode->i_size + 1);
+	inode->i_link = xzalloc(size_add(inode->i_size, 1));
 
 	ret = cramfs_read_file(inode, 0, inode->i_link, inode->i_size);
 	if (ret < 0)
-- 
2.39.5

Re: [PATCH 2/5] CVE-2025-26724: fs: cramfs: fix malloc(size + constant) buffer overflow issues

[Ahmad Fatoum]

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 written to.
> 
> Avoid this by using size_add() instead.

For those unfamiliar with size_add(), it does a saturation addition
and thus xzalloc() will fail as it's impossible to allocate
SIZE_MAX bytes.

> 
> Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>

Thanks,
Ahmad

> ---
>  fs/cramfs/cramfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/cramfs/cramfs.c b/fs/cramfs/cramfs.c
> index e554ebef6f..641a6d2b05 100644
> --- a/fs/cramfs/cramfs.c
> +++ b/fs/cramfs/cramfs.c
> @@ -423,7 +423,7 @@ static const char *cramfs_get_link(struct dentry *dentry, struct inode *inode)
>  {
>  	int ret;
>  
> -	inode->i_link = xzalloc(inode->i_size + 1);
> +	inode->i_link = xzalloc(size_add(inode->i_size, 1));
>  
>  	ret = cramfs_read_file(inode, 0, inode->i_link, inode->i_size);
>  	if (ret < 0)


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 3/5] CVE-2025-26723: fs: ext4: fix malloc(size + constant) buffer overflow issues

[Sascha Hauer]

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() instead.

Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 fs/ext4/ext_barebox.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/ext_barebox.c b/fs/ext4/ext_barebox.c
index 163c4d2fe1..7480c045d7 100644
--- a/fs/ext4/ext_barebox.c
+++ b/fs/ext4/ext_barebox.c
@@ -189,7 +189,7 @@ static const char *ext_get_link(struct dentry *dentry, struct inode *inode)
 
 	BUG_ON(inode->i_link);
 
-	inode->i_link = zalloc(inode->i_size + 1);
+	inode->i_link = zalloc(size_add(inode->i_size, 1));
 
 	ret = ext4fs_read_file(node, 0, inode->i_size, inode->i_link);
 	if (ret == 0) {
-- 
2.39.5

Re: [PATCH 3/5] CVE-2025-26723: fs: ext4: fix malloc(size + constant) buffer overflow issues

[Ahmad Fatoum]

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 written to.
> 
> Avoid this by using size_add() instead.
> 
> Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>

> ---
>  fs/ext4/ext_barebox.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/ext_barebox.c b/fs/ext4/ext_barebox.c
> index 163c4d2fe1..7480c045d7 100644
> --- a/fs/ext4/ext_barebox.c
> +++ b/fs/ext4/ext_barebox.c
> @@ -189,7 +189,7 @@ static const char *ext_get_link(struct dentry *dentry, struct inode *inode)
>  
>  	BUG_ON(inode->i_link);
>  
> -	inode->i_link = zalloc(inode->i_size + 1);
> +	inode->i_link = zalloc(size_add(inode->i_size, 1));
>  
>  	ret = ext4fs_read_file(node, 0, inode->i_size, inode->i_link);
>  	if (ret == 0) {


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 4/5] CVE-2025-26725: fs: jffs2: fix malloc(size + constant) buffer overflow issues

[Sascha Hauer]

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 struct_size() instead.

Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 fs/jffs2/malloc.c    | 4 ++--
 fs/jffs2/nodelist.h  | 2 +-
 fs/jffs2/readinode.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/jffs2/malloc.c b/fs/jffs2/malloc.c
index e0e29fa648..61c2430c18 100644
--- a/fs/jffs2/malloc.c
+++ b/fs/jffs2/malloc.c
@@ -15,10 +15,10 @@
 #include <linux/jffs2.h>
 #include "nodelist.h"
 
-struct jffs2_full_dirent *jffs2_alloc_full_dirent(int namesize)
+struct jffs2_full_dirent *jffs2_alloc_full_dirent(size_t namesize)
 {
 	struct jffs2_full_dirent *ret;
-	ret = kmalloc(sizeof(*ret) + namesize, GFP_KERNEL);
+	ret = kmalloc(struct_size(ret, name, namesize), GFP_KERNEL);
 	dbg_memalloc("%p\n", ret);
 	return ret;
 }
diff --git a/fs/jffs2/nodelist.h b/fs/jffs2/nodelist.h
index d8687319c7..28b35d6d58 100644
--- a/fs/jffs2/nodelist.h
+++ b/fs/jffs2/nodelist.h
@@ -440,7 +440,7 @@ void jffs2_do_clear_inode(struct jffs2_sb_info *c, struct jffs2_inode_info *f);
 
 /* malloc.c */
 
-struct jffs2_full_dirent *jffs2_alloc_full_dirent(int namesize);
+struct jffs2_full_dirent *jffs2_alloc_full_dirent(size_t namesize);
 void jffs2_free_full_dirent(struct jffs2_full_dirent *);
 struct jffs2_full_dnode *jffs2_alloc_full_dnode(void);
 void jffs2_free_full_dnode(struct jffs2_full_dnode *dnode);
diff --git a/fs/jffs2/readinode.c b/fs/jffs2/readinode.c
index 605130d60c..4634ee5818 100644
--- a/fs/jffs2/readinode.c
+++ b/fs/jffs2/readinode.c
@@ -601,7 +601,7 @@ static inline int read_direntry(struct jffs2_sb_info *c, struct jffs2_raw_node_r
 		spin_unlock(&c->erase_completion_lock);
 	}
 
-	fd = jffs2_alloc_full_dirent(rd->nsize + 1);
+	fd = jffs2_alloc_full_dirent(size_add(rd->nsize, 1));
 	if (unlikely(!fd))
 		return -ENOMEM;
 
-- 
2.39.5

Re: [PATCH 4/5] CVE-2025-26725: fs: jffs2: fix malloc(size + constant) buffer overflow issues

[Ahmad Fatoum]

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 then data written to.
> 
> Avoid this by using size_add() and struct_size() instead.
> 
> Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

With below comment addressed:
Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>

> ---
>  fs/jffs2/malloc.c    | 4 ++--
>  fs/jffs2/nodelist.h  | 2 +-
>  fs/jffs2/readinode.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/jffs2/malloc.c b/fs/jffs2/malloc.c
> index e0e29fa648..61c2430c18 100644
> --- a/fs/jffs2/malloc.c
> +++ b/fs/jffs2/malloc.c
> @@ -15,10 +15,10 @@
>  #include <linux/jffs2.h>
>  #include "nodelist.h"
>  
> -struct jffs2_full_dirent *jffs2_alloc_full_dirent(int namesize)
> +struct jffs2_full_dirent *jffs2_alloc_full_dirent(size_t namesize)
>  {
>  	struct jffs2_full_dirent *ret;
> -	ret = kmalloc(sizeof(*ret) + namesize, GFP_KERNEL);
> +	ret = kmalloc(struct_size(ret, name, namesize), GFP_KERNEL);

I was under the impression that struct_size requires the last argument to be
the name of a C99 flexible array member[] and not that of a zero-sized array.

Could you squash a change from struct jffs2_full_dirent::name[0] to ::name[] in 
fs/jffs2/nodelist.h into this commit?

Thanks,
Ahmad

>  	dbg_memalloc("%p\n", ret);
>  	return ret;
>  }
> diff --git a/fs/jffs2/nodelist.h b/fs/jffs2/nodelist.h
> index d8687319c7..28b35d6d58 100644
> --- a/fs/jffs2/nodelist.h
> +++ b/fs/jffs2/nodelist.h
> @@ -440,7 +440,7 @@ void jffs2_do_clear_inode(struct jffs2_sb_info *c, struct jffs2_inode_info *f);
>  
>  /* malloc.c */
>  
> -struct jffs2_full_dirent *jffs2_alloc_full_dirent(int namesize);
> +struct jffs2_full_dirent *jffs2_alloc_full_dirent(size_t namesize);
>  void jffs2_free_full_dirent(struct jffs2_full_dirent *);
>  struct jffs2_full_dnode *jffs2_alloc_full_dnode(void);
>  void jffs2_free_full_dnode(struct jffs2_full_dnode *dnode);
> diff --git a/fs/jffs2/readinode.c b/fs/jffs2/readinode.c
> index 605130d60c..4634ee5818 100644
> --- a/fs/jffs2/readinode.c
> +++ b/fs/jffs2/readinode.c
> @@ -601,7 +601,7 @@ static inline int read_direntry(struct jffs2_sb_info *c, struct jffs2_raw_node_r
>  		spin_unlock(&c->erase_completion_lock);
>  	}
>  
> -	fd = jffs2_alloc_full_dirent(rd->nsize + 1);
> +	fd = jffs2_alloc_full_dirent(size_add(rd->nsize, 1));
>  	if (unlikely(!fd))
>  		return -ENOMEM;
>  


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 5/5] CVE-2025-26721: fs: pstore: fix malloc(size + constant) buffer overflow issues

[Sascha Hauer]

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() instead.

Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 fs/pstore/fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/pstore/fs.c b/fs/pstore/fs.c
index 24b0fa5c9d..706c2d4684 100644
--- a/fs/pstore/fs.c
+++ b/fs/pstore/fs.c
@@ -62,7 +62,7 @@ int pstore_mkfile(struct pstore_record *record)
 			return -EEXIST;
 	}
 
-	private = xzalloc(sizeof(*private) + size);
+	private = xzalloc(struct_size(private, data, size));
 	private->type = record->type;
 	private->id = record->id;
 	private->count = record->count;
-- 
2.39.5

Re: [PATCH 5/5] CVE-2025-26721: fs: pstore: fix malloc(size + constant) buffer overflow issues

[Ahmad Fatoum]

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 written to.
> 
> Avoid this by using struct_size() instead.
> 
> Reported-by: Jonathan Bar Or <jonathanbaror@gmail.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>

> ---
>  fs/pstore/fs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/pstore/fs.c b/fs/pstore/fs.c
> index 24b0fa5c9d..706c2d4684 100644
> --- a/fs/pstore/fs.c
> +++ b/fs/pstore/fs.c
> @@ -62,7 +62,7 @@ int pstore_mkfile(struct pstore_record *record)
>  			return -EEXIST;
>  	}
>  
> -	private = xzalloc(sizeof(*private) + size);
> +	private = xzalloc(struct_size(private, data, size));
>  	private->type = record->type;
>  	private->id = record->id;
>  	private->count = record->count;


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 0/5] Filesystem memory corruption fixes

[Ahmad Fatoum]

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 filesystem in a secure boot chain,
> but instead use FIT images on a raw partition. We never made this explicit
> though. Ahmad has done this recently:
> 
> https://lore.kernel.org/barebox/20250217180949.3961860-3-a.fatoum@pengutronix.de/T/#u
> 
> I digged through the U-Boot code and there are a few CVE fixes in the
> ext4 code that we'll likely need as well. But even with these applied
> we don't consider the barebox filesystems as suitable for secure boot.
> 
> For those curious we consider adding support for dm-verity at some
> point. This would allow us to remove the attack surface from the
> filesystem implementations and we could also use bootspec rather than
> signed FIT images.
> 
> Sascha
> 
> Sascha Hauer (5):
>   CVE-2025-26722: fs: squashfs: Ensure positive inode length
>   CVE-2025-26724: fs: cramfs: fix malloc(size + constant) buffer
>     overflow issues
>   CVE-2025-26723: fs: ext4: fix malloc(size + constant) buffer overflow
>     issues
>   CVE-2025-26725: fs: jffs2: fix malloc(size + constant) buffer overflow
>     issues
>   CVE-2025-26721: fs: pstore: fix malloc(size + constant) buffer
>     overflow issues

I think the CVE id should better go into the commit message body, (maybe
with a Fixes: before it) and not into the title.


Thanks,
Ahmad

> 
>  fs/cramfs/cramfs.c    | 2 +-
>  fs/ext4/ext_barebox.c | 2 +-
>  fs/jffs2/malloc.c     | 4 ++--
>  fs/jffs2/nodelist.h   | 2 +-
>  fs/jffs2/readinode.c  | 2 +-
>  fs/pstore/fs.c        | 2 +-
>  fs/squashfs/symlink.c | 8 ++++++--
>  7 files changed, 13 insertions(+), 9 deletions(-)
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH 0/5] Filesystem memory corruption fixes

[Sascha Hauer]

On Wed, 19 Feb 2025 15:18:39 +0100, 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 filesystem in a secure boot chain,
> but instead use FIT images on a raw partition. We never made this explicit
> though. Ahmad has done this recently:
> 
> [...]

Applied, thanks!

[1/5] CVE-2025-26722: fs: squashfs: Ensure positive inode length
      https://git.pengutronix.de/cgit/barebox/commit/?id=6281a871e2c6 (link may not be stable)
[2/5] CVE-2025-26724: fs: cramfs: fix malloc(size + constant) buffer overflow issues
      https://git.pengutronix.de/cgit/barebox/commit/?id=f86e528c8fba (link may not be stable)
[3/5] CVE-2025-26723: fs: ext4: fix malloc(size + constant) buffer overflow issues
      https://git.pengutronix.de/cgit/barebox/commit/?id=51eea5c16fd2 (link may not be stable)
[4/5] CVE-2025-26725: fs: jffs2: fix malloc(size + constant) buffer overflow issues
      https://git.pengutronix.de/cgit/barebox/commit/?id=e7397340359d (link may not be stable)
[5/5] CVE-2025-26721: fs: pstore: fix malloc(size + constant) buffer overflow issues
      https://git.pengutronix.de/cgit/barebox/commit/?id=7563f5722dfd (link may not be stable)

Best regards,
-- 
Sascha Hauer <s.hauer@pengutronix.de>