[PATCH v2 0/2] qnx4: Avoid confusing compiler about buffer lengths

[PATCH v2 0/2] qnx4: Avoid confusing compiler about buffer lengths

[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/20231112095353.579855-1-debug.penguin32@gmail.com/

v2:
 - Use BUILD_BUG_ON() instead of _Static_assert()
v1: https://lore.kernel.org/all/20231118032638.work.955-kees@kernel.org/

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

-- 
2.34.1

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

[Kees Cook]

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 <al@alarsen.net>
Link: https://lore.kernel.org/r/20231118033225.2181299-1-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 fs/qnx4/dir.c  | 52 ++++++-------------------------------------
 fs/qnx4/qnx4.h | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+), 45 deletions(-)

diff --git a/fs/qnx4/dir.c b/fs/qnx4/dir.c
index 66645a5a35f3..42a529e26bd6 100644
--- a/fs/qnx4/dir.c
+++ b/fs/qnx4/dir.c
@@ -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;
 			}
diff --git a/fs/qnx4/qnx4.h b/fs/qnx4/qnx4.h
index 6283705466a4..5c2b1fb6b952 100644
--- a/fs/qnx4/qnx4.h
+++ b/fs/qnx4/qnx4.h
@@ -44,3 +44,63 @@ static inline struct qnx4_inode_entry *qnx4_raw_inode(struct inode *inode)
 {
 	return &qnx4_i(inode)->raw;
 }
+
+/*
+ * 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 inline const char *get_entry_fname(union qnx4_directory_entry *de,
+					  int *size)
+{
+	/* Make sure the status byte is in the same place for all structs. */
+	BUILD_BUG_ON(offsetof(struct qnx4_inode_entry, di_status) !=
+			offsetof(struct qnx4_link_info, dl_status));
+	BUILD_BUG_ON(offsetof(struct qnx4_inode_entry, di_status) !=
+			offsetof(union qnx4_directory_entry, de_status));
+
+	if (!de->de_name[0])
+		return NULL;
+	if (!(de->de_status & (QNX4_FILE_USED|QNX4_FILE_LINK)))
+		return NULL;
+	if (!(de->de_status & QNX4_FILE_LINK))
+		*size = sizeof(de->inode.di_fname);
+	else
+		*size = sizeof(de->link.dl_fname);
+
+	*size = strnlen(de->de_name, *size);
+
+	return de->de_name;
+}
-- 
2.34.1

[PATCH v2 2/2] qnx4: Use get_directory_fname() in qnx4_match()

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

Cc: Anders Larsen <al@alarsen.net>
Reported-by: Ronald Monthero <debug.penguin32@gmail.com>
Closes: https://lore.kernel.org/lkml/20231112095353.579855-1-debug.penguin32@gmail.com/
Link: https://lore.kernel.org/r/20231118033225.2181299-2-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 fs/qnx4/namei.c | 29 +++++++++++------------------
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/fs/qnx4/namei.c b/fs/qnx4/namei.c
index 8d72221735d7..bb8db6550ca5 100644
--- a/fs/qnx4/namei.c
+++ b/fs/qnx4/namei.c
@@ -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;
 }
 
-- 
2.34.1

Re: [PATCH v2 0/2] qnx4: Avoid confusing compiler about buffer lengths

[Ronald Monthero]

Cheers Kees,
BR,
ronald


On Fri, Dec 1, 2023 at 6:51 AM Kees Cook <keescook@chromium.org> wrote:
>
> 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/20231112095353.579855-1-debug.penguin32@gmail.com/
>
> v2:
>  - Use BUILD_BUG_ON() instead of _Static_assert()
> v1: https://lore.kernel.org/all/20231118032638.work.955-kees@kernel.org/
>
> 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(-)
>
> --
> 2.34.1
>

Re: [PATCH v2 0/2] qnx4: Avoid confusing compiler about buffer lengths

[Kees Cook]

On Tue, Dec 05, 2023 at 01:46:27AM +1000, Ronald Monthero wrote:
> Cheers Kees,
> BR,
> ronald

Is this a "Tested-by"? :)

-Kees

> 
> 
> On Fri, Dec 1, 2023 at 6:51 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > 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/20231112095353.579855-1-debug.penguin32@gmail.com/
> >
> > v2:
> >  - Use BUILD_BUG_ON() instead of _Static_assert()
> > v1: https://lore.kernel.org/all/20231118032638.work.955-kees@kernel.org/
> >
> > 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(-)
> >
> > --
> > 2.34.1
> >

-- 
Kees Cook

Re: [PATCH v2 0/2] qnx4: Avoid confusing compiler about buffer lengths

[Kees Cook]

On Thu, 30 Nov 2023 12:51:17 -0800, Kees Cook wrote:
> 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@gmail.com/
> 
> [...]

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,

-- 
Kees Cook

Re: [PATCH v2 0/2] qnx4: Avoid confusing compiler about buffer lengths

[Anders Larsen]

Hi Kees,

On 2023-12-12 22:19 Kees Cook wrote:
> On Thu, 30 Nov 2023 12:51:17 -0800, Kees Cook wrote:
> > 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/
> > 
> > [...]
> 
> 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 <al@alarsen.net>

Cheers
Anders

Re: [PATCH v2 0/2] qnx4: Avoid confusing compiler about buffer lengths

[Kees Cook]

On Wed, Dec 13, 2023 at 05:43:08PM +0100, Anders Larsen wrote:
> Hi Kees,
> 
> On 2023-12-12 22:19 Kees Cook wrote:
> > On Thu, 30 Nov 2023 12:51:17 -0800, Kees Cook wrote:
> > > 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/
> > > 
> > > [...]
> > 
> > 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 <al@alarsen.net>

Thanks! I'll update the tags. :)

-- 
Kees Cook

Re: [PATCH v2 0/2] qnx4: Avoid confusing compiler about buffer lengths

[Ronald Monthero]

On Tue, Dec 5, 2023 at 8:10 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Tue, Dec 05, 2023 at 01:46:27AM +1000, Ronald Monthero wrote:
> > Cheers Kees,
> > BR,
> > ronald
>
> Is 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