linux-kernel - Fwd: Kernel panic on listing QNX4 fs directory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <7fa629b5-74bb-43a2-a1bc-38c4a221b30c@gmail.com>
Date:   Sun, 12 Nov 2023 20:07:53 +0700
From:   Bagas Sanjaya <bagasdotme@...il.com>
To:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Filesystem Development <linux-fsdevel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>
Cc:     Anders Larsen <al@...rsen.net>, Al Viro <viro@...iv.linux.org.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        Niek Nooijens <nieknooijens@...il.com>,
        Monthero Ronald <rhmcruiser@...il.com>
Subject: Fwd: Kernel panic on listing QNX4 fs directory

Hi,

I notice a bug report on Bugzilla [1]. Quoting from it:

> When mounting a QNX4 filesystem in linux 6.6.0 (latest mainline) listing a directory may fail and cause a kernel panic.
> 
> 
> First discovered on ubuntu's own kernel, however I was curious if this was ubuntu-specific. turned out it wasn't. I compiled 6.6.0 from scratch with the attached config.
> 
> 
> steps to reproduce:
> 1. grab 6.6.0 from kernel.org main page.
> 2. apply attached config
> 3. make modules_install
> 4. sudo make install
> 5. reboot into new kernel
> 6. open disk image with disk image mounter (attaches it to /dev/loop30)
> 7. mount /dev/loop30p3 /mnt #(qnx partition) 
> 8. cd /dmnt
> 9. execute ls a few times in different directories.
> 
> 
> the first ls will give a [detected buffer overflow in strlen] kernel message.
> after a few times it completely hangs. 
> 
> 
> /var/log/kern.log reveals a full on panic:
> 
> Nov  7 10:34:09 noonie-T580-Linux kernel: [  234.756173] kernel BUG at lib/string.c:1165!
> Nov  7 10:34:09 noonie-T580-Linux kernel: [  234.756184] invalid opcode: 0000 [#1] SMP PTI
> ....
> 
> Full log is in the attachment.

Another reporter pinned down the cause:

> Checking the provided kernel log and config the below is what seems to be cause of the panic during the lookup operation of the qnx4 directory 
> 
> Panic dump stack indicates string length buffer overflow 
> and it is at below context during  qnx4_lookup() => qnx4_find_entry() => qnx4_match()
> 
>     [ 4849.636861] detected buffer overflow in strlen
>     [ 4849.636897] ------------[ cut here ]------------
>     [ 4849.636902] kernel BUG at lib/string.c:1165!
>     [ 4849.636917] invalid opcode: 0000 [#2] SMP PTI
>     ..
>     [ 4849.637047] Call Trace:
>     [ 4849.637053]  <TASK>
>     [ 4849.637059]  ? show_trace_log_lvl+0x1d6/0x2ea
>     [ 4849.637075]  ? show_trace_log_lvl+0x1d6/0x2ea
>     [ 4849.637095]  ? qnx4_find_entry.cold+0xc/0x18 [qnx4]
>     [ 4849.637111]  ? show_regs.part.0+0x23/0x29
>     [ 4849.637123]  ? __die_body.cold+0x8/0xd
>     [ 4849.637135]  ? __die+0x2b/0x37
>     [ 4849.637147]  ? die+0x30/0x60
>     [ 4849.637161]  ? do_trap+0xbe/0x100
>     [ 4849.637171]  ? do_error_trap+0x6f/0xb0
>     [ 4849.637180]  ? fortify_panic+0x13/0x15
>     [ 4849.637192]  ? exc_invalid_op+0x53/0x70
>     [ 4849.637203]  ? fortify_panic+0x13/0x15
>     [ 4849.637215]  ? asm_exc_invalid_op+0x1b/0x20
>     [ 4849.637228]  ? fortify_panic+0x13/0x15
>     [ 4849.637240]  ? fortify_panic+0x13/0x15
>     [ 4849.637251]  qnx4_find_entry.cold+0xc/0x18 [qnx4]
>     [ 4849.637264]  qnx4_lookup+0x3c/0xa0 [qnx4]
>     [ 4849.637275]  __lookup_slow+0x85/0x150
>     [ 4849.637291]  walk_component+0x145/0x1c0
>     [ 4849.637304]  ? path_init+0x2c0/0x3f0
>     [ 4849.637316]  path_lookupat+0x6e/0x1c0
>     [ 4849.637330]  filename_lookup+0xcf/0x1d0
>     [ 4849.637341]  ? __check_object_size+0x1d/0x30
>     [ 4849.637354]  ? strncpy_from_user+0x44/0x150
>     [ 4849.637365]  ? getname_flags.part.0+0x4c/0x1b0
>     [ 4849.637375]  user_path_at_empty+0x3f/0x60
>     [ 4849.637383]  vfs_statx+0x7a/0x130
>     [ 4849.637393]  do_statx+0x45/0x80
>     ..
> 
> ( in kernel config  CONFIG_FORTIFY_SOURCE=y ) 
> 
> linux-git$ git describe 
> v6.6-16177-gea69f5e8240
> 
> static int qnx4_match(int len, const char *name,
>                       struct buffer_head *bh, unsigned long *offset)
> {
>         struct qnx4_inode_entry *de;
>         int namelen, thislen;
> 
>         if (bh == NULL) {
>                 printk(KERN_WARNING "qnx4: matching unassigned buffer !\n");
>                 return 0;
>         }
>         de = (struct qnx4_inode_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 );     << [1]  buffer overflow 
>         if ( thislen > namelen )
>                 thislen = namelen;
>         if (len != thislen) {
>                 return 0;
>         }
> 
> [reply] [−] Comment 2 

See Bugzilla for the full thread, attached kernel log, and proposed fix.

Thanks.

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=218111

-- 
An old man doll... just what I always wanted! - Clara