* [PATCH 0/2] qnx4: Avoid confusing compiler about buffer lengths
@ 2023-11-18 3:32 Kees Cook
2023-11-18 3:32 ` [PATCH 1/2] qnx4: Extract dir entry filename processing into helper Kees Cook
2023-11-18 3:32 ` [PATCH 2/2] qnx4: Use get_directory_fname() in qnx4_match() Kees Cook
0 siblings, 2 replies; 5+ messages in thread
From: Kees Cook @ 2023-11-18 3:32 UTC (permalink / raw)
To: Anders Larsen; +Cc: Kees Cook, Ronald Monthero, linux-kernel, linux-hardening
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/
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(-)
--
2.34.1
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 1/2] qnx4: Extract dir entry filename processing into helper
2023-11-18 3:32 [PATCH 0/2] qnx4: Avoid confusing compiler about buffer lengths Kees Cook
@ 2023-11-18 3:32 ` Kees Cook
2023-11-18 15:01 ` kernel test robot
2023-11-18 18:00 ` kernel test robot
2023-11-18 3:32 ` [PATCH 2/2] qnx4: Use get_directory_fname() in qnx4_match() Kees Cook
1 sibling, 2 replies; 5+ messages in thread
From: Kees Cook @ 2023-11-18 3:32 UTC (permalink / raw)
To: Anders Larsen; +Cc: Kees Cook, Ronald Monthero, linux-kernel, linux-hardening
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>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
fs/qnx4/dir.c | 52 ++++++--------------------------------------
fs/qnx4/qnx4.h | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 66 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..0b6b86ee09dd 100644
--- a/fs/qnx4/qnx4.h
+++ b/fs/qnx4/qnx4.h
@@ -44,3 +44,62 @@ 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;
+};
+/* Make sure the status byte is in the same place for all structs. */
+_Static_assert(offsetof(struct qnx4_inode_entry, di_status) ==
+ offsetof(struct qnx4_link_info, dl_status));
+_Static_assert(offsetof(struct qnx4_inode_entry, di_status) ==
+ offsetof(union qnx4_directory_entry, de_status));
+
+static inline const char *get_entry_fname(union qnx4_directory_entry *de,
+ int *size)
+{
+ 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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH 2/2] qnx4: Use get_directory_fname() in qnx4_match()
2023-11-18 3:32 [PATCH 0/2] qnx4: Avoid confusing compiler about buffer lengths Kees Cook
2023-11-18 3:32 ` [PATCH 1/2] qnx4: Extract dir entry filename processing into helper Kees Cook
@ 2023-11-18 3:32 ` Kees Cook
1 sibling, 0 replies; 5+ messages in thread
From: Kees Cook @ 2023-11-18 3:32 UTC (permalink / raw)
To: Anders Larsen; +Cc: Kees Cook, Ronald Monthero, linux-kernel, linux-hardening
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/
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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 1/2] qnx4: Extract dir entry filename processing into helper
2023-11-18 3:32 ` [PATCH 1/2] qnx4: Extract dir entry filename processing into helper Kees Cook
@ 2023-11-18 15:01 ` kernel test robot
2023-11-18 18:00 ` kernel test robot
1 sibling, 0 replies; 5+ messages in thread
From: kernel test robot @ 2023-11-18 15:01 UTC (permalink / raw)
To: Kees Cook, Anders Larsen
Cc: oe-kbuild-all, Kees Cook, Ronald Monthero, linux-kernel,
linux-hardening
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/202311182210.gREgIbSb-lkp@intel.com/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/202311182210.gREgIbSb-lkp@intel.com/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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311182210.gREgIbSb-lkp@intel.com/
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
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/2] qnx4: Extract dir entry filename processing into helper
2023-11-18 3:32 ` [PATCH 1/2] qnx4: Extract dir entry filename processing into helper Kees Cook
2023-11-18 15:01 ` kernel test robot
@ 2023-11-18 18:00 ` kernel test robot
1 sibling, 0 replies; 5+ messages in thread
From: kernel test robot @ 2023-11-18 18:00 UTC (permalink / raw)
To: Kees Cook, Anders Larsen
Cc: llvm, oe-kbuild-all, Kees Cook, Ronald Monthero, linux-kernel,
linux-hardening
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/202311190108.LDeSe9Lj-lkp@intel.com/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/202311190108.LDeSe9Lj-lkp@intel.com/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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311190108.LDeSe9Lj-lkp@intel.com/
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
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-11-18 18:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-18 3:32 [PATCH 0/2] qnx4: Avoid confusing compiler about buffer lengths Kees Cook
2023-11-18 3:32 ` [PATCH 1/2] qnx4: Extract dir entry filename processing into helper Kees Cook
2023-11-18 15:01 ` kernel test robot
2023-11-18 18:00 ` kernel test robot
2023-11-18 3:32 ` [PATCH 2/2] qnx4: Use get_directory_fname() in qnx4_match() Kees Cook
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox