qnx4: Avoid confusing compiler about buffer lengths
v2 cover qnx4: Avoid confusing compiler about buffer lengths
Hi,
This attempts to fix the issue Ronald Monthero found[1]. Avoids using a too-short struct buffer when reading the string, by using the existing struct union.
-Kees
[1] https://lore.kernel.org/lkml/[email protected]/
v2:
- Use BUILD_BUG_ON() instead of _Static_assert()
v1: https://lore.kernel.org/all/[email protected]/
Kees Cook (2):
qnx4: Extract dir entry filename processing into helper
qnx4: Use get_directory_fname() in qnx4_match()
fs/qnx4/dir.c | 52 ++++++------------------------------------ fs/qnx4/namei.c | 29 +++++++++--------------- fs/qnx4/qnx4.h | 60 +++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 78 insertions(+), 63 deletions(-)
Signature · 1 line
2.34.1
PATCH v2 1/2 qnx4: Extract dir entry filename processing into helper
Both dir.c and namei.c need to perform the same work to figure out a directory entry's name and size. Extract this into a helper for use in the next patch.
--- fs/qnx4/dir.c | 52 ++++++------------------------------------- fs/qnx4/qnx4.h | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+), 45 deletions(-)
fs/qnx4/dir.c +7 -45
@@ -15,43 +15,6 @@#include <linux/buffer_head.h> #include "qnx4.h" -/* -* A qnx4 directory entry is an inode entry or link info -* depending on the status field in the last byte. The -* first byte is where the name start either way, and a -* zero means it's empty. -* -* Also, due to a bug in gcc, we don't want to use the -* real (differently sized) name arrays in the inode and -* link entries, but always the 'de_name[]' one in the -* fake struct entry. -* -* See -* -* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c6 -* -* for details, but basically gcc will take the size of the -* 'name' array from one of the used union entries randomly. -* -* This use of 'de_name[]' (48 bytes) avoids the false positive -* warnings that would happen if gcc decides to use 'inode.di_name' -* (16 bytes) even when the pointer and size were to come from -* 'link.dl_name' (48 bytes). -* -* In all cases the actual name pointer itself is the same, it's -* only the gcc internal 'what is the size of this field' logic -* that can get confused. -*/ -union qnx4_directory_entry { -struct { -const char de_name[48 ]; -u8 de_pad[15 ]; -u8 de_status; - }; -struct qnx4_inode_entry inode; -struct qnx4_link_info link; -}; -static int qnx4_readdir (struct file *file,struct dir_context *ctx) {struct inode *inode =file_inode (file);
@@ -74,26 +37,25 @@ static int qnx4_readdir(struct file *file, struct dir_context *ctx) ix = (ctx->pos >>QNX4_DIR_ENTRY_SIZE_BITS ) %QNX4_INODES_PER_BLOCK ;for (; ix <QNX4_INODES_PER_BLOCK ; ix++, ctx->pos +=QNX4_DIR_ENTRY_SIZE ) {union qnx4_directory_entry *de; +const char *fname; offset = ix *QNX4_DIR_ENTRY_SIZE ; de = (union qnx4_directory_entry *) (bh->b_data + offset); -if (!de->de_name[0 ]) -continue ; -if (!(de->de_status & (QNX4_FILE_USED |QNX4_FILE_LINK ))) + fname =get_entry_fname (de, &size); +if (!fname)continue ; +if (!(de->de_status &QNX4_FILE_LINK )) { - size =sizeof (de->inode.di_fname); ino = blknum *QNX4_INODES_PER_BLOCK + ix -1 ; }else { - size =sizeof (de->link.dl_fname); ino = (le32_to_cpu (de->link.dl_inode_blk) -1 ) *QNX4_INODES_PER_BLOCK + de->link.dl_inode_ndx; } - size =strnlen (de->de_name, size); -QNX4DEBUG ((KERN_INFO "qnx4_readdir:%.*s\n" , size, name)); -if (!dir_emit (ctx, de->de_name, size, ino,DT_UNKNOWN )) { + +QNX4DEBUG ((KERN_INFO "qnx4_readdir:%.*s\n" , size, fname)); +if (!dir_emit (ctx, fname, size, ino,DT_UNKNOWN )) {brelse (bh);return 0 ; }
fs/qnx4/qnx4.h +60 -0
63 lines not on this page · raw message
Signature · 1 line
2.34.1
PATCH v2 2/2 qnx4: Use get_directory_fname() in qnx4_match()
In reply to Kees CookUse the new common directory entry name accessor helper to avoid confusing the compiler about over-running the file name buffer. Avoids false positive buffer overflow warning:
[ 4849.636861] detected buffer overflow in strlen [ 4849.636897] ------------[ cut here ]------------ [ 4849.636902] kernel BUG at lib/string.c:1165! ... [ 4849.637047] Call Trace: ... [ 4849.637251] qnx4_find_entry.cold+0xc/0x18 [qnx4] [ 4849.637264] qnx4_lookup+0x3c/0xa0 [qnx4]
--- fs/qnx4/namei.c | 29 +++++++++++------------------ 1 file changed, 11 insertions(+), 18 deletions(-)
fs/qnx4/namei.c +11 -18
@@ -26,31 +26,24 @@static int qnx4_match (int len,const char *name,struct buffer_head *bh,unsigned long *offset) { -struct qnx4_inode_entry *de; -int namelen, thislen; +union qnx4_directory_entry *de; +const char *fname; +int fnamelen;if (bh ==NULL ) {printk (KERN_WARNING "qnx4: matching unassigned buffer !\n" );return 0 ; } - de = (struct qnx4_inode_entry *) (bh->b_data + *offset); + de = (union qnx4_directory_entry *) (bh->b_data + *offset); *offset +=QNX4_DIR_ENTRY_SIZE ; -if ((de->di_status &QNX4_FILE_LINK ) !=0 ) { - namelen =QNX4_NAME_MAX ; - }else { - namelen =QNX4_SHORT_NAME_MAX ; - } - thislen =strlen ( de->di_fname ); -if ( thislen > namelen ) - thislen = namelen; -if (len != thislen) { + + fname =get_entry_fname (de, &fnamelen); +if (!fname || len != fnamelen)return 0 ; - } -if (strncmp (name, de->di_fname, len) ==0 ) { -if ((de->di_status & (QNX4_FILE_USED |QNX4_FILE_LINK )) !=0 ) { -return 1 ; - } - } + +if (strncmp (name, fname, len) ==0 ) +return 1 ; +return 0 ; }
Signature · 1 line
2.34.1
Cheers Kees,
BR,
ronald
Quoted 27 lines · Kees Cook
Hi,
This attempts to fix the issue Ronald Monthero found[1]. Avoids using a too-short struct buffer when reading the string, by using the existing struct union.
-Kees
[1] https://lore.kernel.org/lkml/[email protected]/
v2:
- UseBUILD_BUG_ON()instead of_Static_assert()
v1: https://lore.kernel.org/all/[email protected]/Kees Cook (2):
qnx4: Extract dir entry filename processing into helper
qnx4: Useget_directory_fname()inqnx4_match()fs/qnx4/dir.c | 52 ++++++------------------------------------ fs/qnx4/namei.c | 29 +++++++++--------------- fs/qnx4/qnx4.h | 60 +++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 78 insertions(+), 63 deletions(-)--
2.34.1
Quoted 3 lines · Ronald Monthero
Cheers Kees,
BR,
ronald
Is this a "Tested-by"? :)
-Kees
Quoted 30 lines · Kees Cook
Quoted 27 lines
Hi,
This attempts to fix the issue Ronald Monthero found[1]. Avoids using a too-short struct buffer when reading the string, by using the existing struct union.
-Kees
[1] https://lore.kernel.org/lkml/[email protected]/
v2:
- UseBUILD_BUG_ON()instead of_Static_assert()
v1: https://lore.kernel.org/all/[email protected]/Kees Cook (2):
qnx4: Extract dir entry filename processing into helper
qnx4: Useget_directory_fname()inqnx4_match()fs/qnx4/dir.c | 52 ++++++------------------------------------ fs/qnx4/namei.c | 29 +++++++++--------------- fs/qnx4/qnx4.h | 60 +++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 78 insertions(+), 63 deletions(-)--
2.34.1
Signature · 1 line
Kees Cook
Quoted 7 lines · Kees Cook
Quoted 3 lines · Ronald Monthero
Cheers Kees,
BR,
ronaldIs this a "Tested-by"? :)
Oh sorry Kees I have somehow missed this conversation.
Yes ack the tests which were earlier causing oops, now pass with the 2 patches.
BR,
ronald
Kees Cook
AppliedQuoted 9 lines · Kees Cook
This attempts to fix the issue Ronald Monthero found[1]. Avoids using a too-short struct buffer when reading the string, by using the existing struct union.
-Kees
[1] https://lore.kernel.org/lkml/[email protected]/
[...]
I'll put these in -next since there's been no more discussion on it.
Applied to for-next/hardening, thanks!
[1/2] qnx4: Extract dir entry filename processing into helper
https://git.kernel.org/kees/c/49a85c02a189 [2/2] qnx4: Use get_directory_fname() in qnx4_match() https://git.kernel.org/kees/c/0a0fb20f5e08
Take care,
Signature · 1 line
Kees Cook
Hi Kees,
Quoted 11 lines · On 2023-12-12 22:19 Kees Cook wrote:
Quoted 10 lines · Kees Cook
This attempts to fix the issue Ronald Monthero found[1]. Avoids using a too-short struct buffer when reading the string, by using the existing struct union.
-Kees
[1]
https://lore.kernel.org/lkml/20231112095353.579855-1-debug.penguin32@gmai
l.com/
Quoted 5 lines
Quoted 1 line
[...]
I'll put these in -next since there's been no more discussion on it.
Applied to for-next/hardening, thanks!
thanks for taking care of this (and apologies for me being unresponsive)
If it's not too late, feel free to add
Cheers
Anders
Quoted 16 lines · Anders Larsen
Hi Kees,
Quoted 13 lines · On 2023-12-12 22:19 Kees Cook wrote:
Quoted 11 lines · Kees Cook
This attempts to fix the issue Ronald Monthero found[1]. Avoids using a too-short struct buffer when reading the string, by using the existing struct union.
-Kees
[1]
https://lore.kernel.org/lkml/20231112095353.579855-1-debug.penguin32@gmai
l.com/[...]
Quoted 8 lines
Quoted 3 lines
I'll put these in -next since there's been no more discussion on it.
Applied to for-next/hardening, thanks!
thanks for taking care of this (and apologies for me being unresponsive)
If it's not too late, feel free to add
Acked-by Anders Larsen <[email protected]>
Thanks! I'll update the tags. :)
Signature · 1 line
Kees Cook