Subject:[REGRESSION] fs/qnx6: incorrect pointer arithmetic breaks dir scanning completely

Subject:[REGRESSION] fs/qnx6: incorrect pointer arithmetic breaks dir scanning completely

[Oleg Chaun]

#regzbot introduced: b2aa615

Hello,

A change to fs/qnx6/dir.c:qnx6_readdir() introduced in commit b2aa615 
contains an incorrect pointer arithmetic (adding an offset expressed in 
QNX6_DIR_ENTRY_SIZE units to a plain char * pointer) which breaks QNX6 
directory reading completely: only few entries are visible, kernel log 
is spammed with "invalid direntry size" messages.

The following patch seems to fix the issue:

--- /tmp/temp/linux-6.17/fs/qnx6/dir.c    2025-09-28 23:39:22.000000000 
+0200
+++ ./dir.c    2026-02-13 18:52:56.000000000 +0100
@@ -138,8 +138,8 @@
              ctx->pos = (n + 1) << PAGE_SHIFT;
              return PTR_ERR(kaddr);
          }
-        de = (struct qnx6_dir_entry *)(kaddr + offset);
-        limit = kaddr + last_entry(inode, n);
+        de = ((struct qnx6_dir_entry *)kaddr) + offset;
+        limit = kaddr + last_entry(inode, n) * QNX6_DIR_ENTRY_SIZE;
          for (; (char *)de < limit; de++, ctx->pos += 
QNX6_DIR_ENTRY_SIZE) {
              int size = de->de_size;
              u32 no_inode = fs32_to_cpu(sbi, de->de_inode);

I can test any further changes on real QNX6 fs images if necessary.

BR,
Oleg

Re: Subject:[REGRESSION] fs/qnx6: incorrect pointer arithmetic breaks dir scanning completely

[Thorsten Leemhuis]

On 5/26/26 12:40, Oleg Chaun wrote:
> 
> A change to fs/qnx6/dir.c:qnx6_readdir() introduced in commit b2aa615
> contains an incorrect pointer arithmetic (adding an offset expressed in
> QNX6_DIR_ENTRY_SIZE units to a plain char * pointer) which breaks QNX6
> directory reading completely: only few entries are visible, kernel log
> is spammed with "invalid direntry size" messages.

Thx for the report. From a quick look it seems Arpith Kalaginanavoor
(now CCed) reported this last month and provided a proper patch:
https://lore.kernel.org/all/20260310102233.391113-1-arpithk@nvidia.com/

Al (now CCed, too) suggested a slightly different fix, but it seems
since then nothing happened.

Ciao, Thorsten

> The following patch seems to fix the issue:
> 
> --- /tmp/temp/linux-6.17/fs/qnx6/dir.c    2025-09-28 23:39:22.000000000
> +0200
> +++ ./dir.c    2026-02-13 18:52:56.000000000 +0100
> @@ -138,8 +138,8 @@
>              ctx->pos = (n + 1) << PAGE_SHIFT;
>              return PTR_ERR(kaddr);
>          }
> -        de = (struct qnx6_dir_entry *)(kaddr + offset);
> -        limit = kaddr + last_entry(inode, n);
> +        de = ((struct qnx6_dir_entry *)kaddr) + offset;
> +        limit = kaddr + last_entry(inode, n) * QNX6_DIR_ENTRY_SIZE;
>          for (; (char *)de < limit; de++, ctx->pos +=
> QNX6_DIR_ENTRY_SIZE) {
>              int size = de->de_size;
>              u32 no_inode = fs32_to_cpu(sbi, de->de_inode);
> 
> I can test any further changes on real QNX6 fs images if necessary.

#regzbot introduced: b2aa61556fcfa8
#regzbot title: qnx6: dir scanning broken
#regzbot dup:
https://lore.kernel.org/all/20260310102233.391113-1-arpithk@nvidia.com/

Re: Subject:[REGRESSION] fs/qnx6: incorrect pointer arithmetic breaks dir scanning completely

[Arpith Kalaginanavoor]

Hi Thorsten,

I have submitted a revised fix for this here:
https://lore.kernel.org/all/20260526123858.1683035-1-arpithk@nvidia.com/

This follows Al's suggested approach from the earlier thread.

Thanks,
Arpith

Re: Subject:[REGRESSION] fs/qnx6: incorrect pointer arithmetic breaks dir scanning completely

[Sasha Levin]

On Tue, May 26, 2026 at 12:40:12PM +0200, Oleg Chaun wrote:
> Commit b2aa61556fcf ("qnx6: Convert qnx6_get_page() to
> qnx6_get_folio()") breaks qnx6 readdir on 6.12, 6.18 and 7.0 by
> dropping the QNX6_DIR_ENTRY_SIZE scaling in the entry-pointer
> arithmetic.

Thanks for the report. As Thorsten noted, Arpith already posted a fix
at:

  https://lore.kernel.org/all/20260310102233.391113-1-arpithk@nvidia.com/

with Al Viro's review feedback still pending. There is no upstream
commit to cherry-pick yet, so I cannot queue anything for stable until
an upstream fix lands.

-- 
Thanks,
Sasha