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