Skip to contentSkip to conversation

qnx4: Avoid confusing compiler about buffer lengths

PATCH Superseded Kees Cook 2 participants 5 messages Nov 18, 2023 QNX4 filesystem

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Kees Cook

author
#0 lore raw

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]/

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  | 59 +++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 77 insertions(+), 63 deletions(-)
Signature · 1 line
2.34.1
author
#1 lore raw

PATCH 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.

Cc Anders Larsen <[email protected]>
---
 fs/qnx4/dir.c  | 52 ++++++--------------------------------------
 fs/qnx4/qnx4.h | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+), 45 deletions(-)
fs/qnx4/dir.c +7 -45
index 66645a5a35f3..42a529e26bd6 100644
@@ -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 +59 -0

62 lines not on this page · raw message

Signature · 1 line
2.34.1
#2 lore raw

Re: [PATCH 1/2] qnx4: Extract dir entry filename processing into helper

kernel test robot noticed the following build errors:

Hi Kees,

kernel test robot noticed the following build errors:

[auto build test ERROR on linus/master]
[also build test ERROR on v6.7-rc1 next-20231117]
[If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Kees-Cook/qnx4-Extract-dir-entry-filename-processing-into-helper/20231118-114223
base:   linus/master
patch link:    https://lore.kernel.org/r/20231118033225.2181299-1-keescook%40chromium.org
patch subject: [PATCH 1/2] qnx4: Extract dir entry filename processing into helper
config: i386-randconfig-011-20231118 (https://download.01.org/0day-ci/archive/20231118/[email protected]/config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231118/[email protected]/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

All errors (new ones prefixed by >>):

In file included from fs/qnx4/dir.c:16:0:

>> fs/qnx4/qnx4.h:86:51: error: expected ',' before ')' token
            offsetof(struct qnx4_link_info, dl_status));
                                                      ^
   fs/qnx4/qnx4.h:88:56: error: expected ',' before ')' token
            offsetof(union qnx4_directory_entry, de_status));
                                                           ^

vim +86 fs/qnx4/qnx4.h

    47	
    48	/*
    49	 * A qnx4 directory entry is an inode entry or link info
    50	 * depending on the status field in the last byte. The
    51	 * first byte is where the name start either way, and a
    52	 * zero means it's empty.
    53	 *
    54	 * Also, due to a bug in gcc, we don't want to use the
    55	 * real (differently sized) name arrays in the inode and
    56	 * link entries, but always the 'de_name[]' one in the
    57	 * fake struct entry.
    58	 *
    59	 * See
    60	 *
    61	 *   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c6
    62	 *
    63	 * for details, but basically gcc will take the size of the
    64	 * 'name' array from one of the used union entries randomly.
    65	 *
    66	 * This use of 'de_name[]' (48 bytes) avoids the false positive
    67	 * warnings that would happen if gcc decides to use 'inode.di_name'
    68	 * (16 bytes) even when the pointer and size were to come from
    69	 * 'link.dl_name' (48 bytes).
    70	 *
    71	 * In all cases the actual name pointer itself is the same, it's
    72	 * only the gcc internal 'what is the size of this field' logic
    73	 * that can get confused.
    74	 */
    75	union qnx4_directory_entry {
    76		struct {
    77			const char de_name[48];
    78			u8 de_pad[15];
    79			u8 de_status;
    80		};
    81		struct qnx4_inode_entry inode;
    82		struct qnx4_link_info link;
    83	};
    84	/* Make sure the status byte is in the same place for all structs. */
    85	_Static_assert(offsetof(struct qnx4_inode_entry, di_status) ==
  > 86		       offsetof(struct qnx4_link_info, dl_status));
    87	_Static_assert(offsetof(struct qnx4_inode_entry, di_status) ==
    88		       offsetof(union qnx4_directory_entry, de_status));
    89	
Signature · 2 lines
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
#3 lore raw

Re: [PATCH 1/2] qnx4: Extract dir entry filename processing into helper

In reply to Kees Cook
kernel test robot noticed the following build warnings:

Hi Kees,

kernel test robot noticed the following build warnings:

[auto build test WARNING on linus/master]
[also build test WARNING on v6.7-rc1 next-20231117]
[If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Kees-Cook/qnx4-Extract-dir-entry-filename-processing-into-helper/20231118-114223
base:   linus/master
patch link:    https://lore.kernel.org/r/20231118033225.2181299-1-keescook%40chromium.org
patch subject: [PATCH 1/2] qnx4: Extract dir entry filename processing into helper
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20231119/[email protected]/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231119/[email protected]/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

All warnings (new ones prefixed by >>):

In file included from fs/qnx4/inode.c:20:
In file included from include/linux/pagemap.h:11:
In file included from include/linux/highmem.h:12:
In file included from include/linux/hardirq.h:11:
In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/hexagon/include/asm/io.h:337:
include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]

     547 |         val = __raw_readb(PCI_IOBASE + addr);
         |                           ~~~~~~~~~~ ^
   include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     560 |         val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
         |                                                         ~~~~~~~~~~ ^
   include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu'
      37 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
         |                                                   ^
   In file included from fs/qnx4/inode.c:20:
   In file included from include/linux/pagemap.h:11:
   In file included from include/linux/highmem.h:12:
   In file included from include/linux/hardirq.h:11:
   In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
   In file included from include/asm-generic/hardirq.h:17:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/hexagon/include/asm/io.h:337:
   include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     573 |         val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
         |                                                         ~~~~~~~~~~ ^
   include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu'
      35 | #define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
         |                                                   ^
   In file included from fs/qnx4/inode.c:20:
   In file included from include/linux/pagemap.h:11:
   In file included from include/linux/highmem.h:12:
   In file included from include/linux/hardirq.h:11:
   In file included from ./arch/hexagon/include/generated/asm/hardirq.h:1:
   In file included from include/asm-generic/hardirq.h:17:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/hexagon/include/asm/io.h:337:
   include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     584 |         __raw_writeb(value, PCI_IOBASE + addr);
         |                             ~~~~~~~~~~ ^
   include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     594 |         __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
         |                                                       ~~~~~~~~~~ ^
   include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
     604 |         __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
         |                                                       ~~~~~~~~~~ ^
   In file included from fs/qnx4/inode.c:24:
>> fs/qnx4/qnx4.h:86:51: warning: '_Static_assert' with no message is a C2x extension [-Wc2x-extensions]
      86 |                offsetof(struct qnx4_link_info, dl_status));
         |                                                          ^
         |                                                          , ""
   fs/qnx4/qnx4.h:88:56: warning: '_Static_assert' with no message is a C2x extension [-Wc2x-extensions]
      88 |                offsetof(union qnx4_directory_entry, de_status));
         |                                                               ^
         |                                                               , ""

8 warnings generated.

vim +/_Static_assert +86 fs/qnx4/qnx4.h

    47	
    48	/*
    49	 * A qnx4 directory entry is an inode entry or link info
    50	 * depending on the status field in the last byte. The
    51	 * first byte is where the name start either way, and a
    52	 * zero means it's empty.
    53	 *
    54	 * Also, due to a bug in gcc, we don't want to use the
    55	 * real (differently sized) name arrays in the inode and
    56	 * link entries, but always the 'de_name[]' one in the
    57	 * fake struct entry.
    58	 *
    59	 * See
    60	 *
    61	 *   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c6
    62	 *
    63	 * for details, but basically gcc will take the size of the
    64	 * 'name' array from one of the used union entries randomly.
    65	 *
    66	 * This use of 'de_name[]' (48 bytes) avoids the false positive
    67	 * warnings that would happen if gcc decides to use 'inode.di_name'
    68	 * (16 bytes) even when the pointer and size were to come from
    69	 * 'link.dl_name' (48 bytes).
    70	 *
    71	 * In all cases the actual name pointer itself is the same, it's
    72	 * only the gcc internal 'what is the size of this field' logic
    73	 * that can get confused.
    74	 */
    75	union qnx4_directory_entry {
    76		struct {
    77			const char de_name[48];
    78			u8 de_pad[15];
    79			u8 de_status;
    80		};
    81		struct qnx4_inode_entry inode;
    82		struct qnx4_link_info link;
    83	};
    84	/* Make sure the status byte is in the same place for all structs. */
    85	_Static_assert(offsetof(struct qnx4_inode_entry, di_status) ==
  > 86		       offsetof(struct qnx4_link_info, dl_status));
    87	_Static_assert(offsetof(struct qnx4_inode_entry, di_status) ==
    88		       offsetof(union qnx4_directory_entry, de_status));
    89	
Signature · 2 lines
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
author
#4 lore raw

PATCH 2/2 qnx4: Use get_directory_fname() in qnx4_match()

In reply to Kees Cook

Use 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
index 8d72221735d7..bb8db6550ca5 100644
@@ -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