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
