[syzbot] [ocfs2?] KASAN: use-after-free Read in ocfs2_listxattr

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: e424ed997df8 Merge remote-tracking branch 'will/for-next/p..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=1739c412580000
kernel config: https://syzkaller.appspot.com/x/.config?x=b8b659f0cab27b22
dashboard link: https://syzkaller.appspot.com/bug?extid=ab0ad25088673470d2d9
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
userspace arch: arm64
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1531aa92580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1361d084580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/ada05b916921/disk-e424ed99.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/674414e6bfd1/vmlinux-e424ed99.xz
kernel image: https://storage.googleapis.com/syzbot-assets/67ca98bd56a6/Image-e424ed99.gz.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/5d507ac2b3e1/mount_0.gz
fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=11310412580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ab0ad2...@syzkaller.appspotmail.com

On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
OCFS2: File system is now read-only.
==================================================================
BUG: KASAN: use-after-free in ocfs2_xattr_get_type fs/ocfs2/ocfs2_fs.h:1114 [inline]
BUG: KASAN: use-after-free in ocfs2_xattr_list_entries fs/ocfs2/xattr.c:934 [inline]
BUG: KASAN: use-after-free in ocfs2_xattr_ibody_list fs/ocfs2/xattr.c:982 [inline]
BUG: KASAN: use-after-free in ocfs2_listxattr+0x408/0xa74 fs/ocfs2/xattr.c:1044
Read of size 1 at addr ffff0000eba98007 by task syz.0.17/6724

CPU: 1 UID: 0 PID: 6724 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/03/2025
Call trace:
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:499 (C)
__dump_stack+0x30/0x40 lib/dump_stack.c:94
dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120
print_address_description+0xa8/0x238 mm/kasan/report.c:378
print_report+0x68/0x84 mm/kasan/report.c:482
kasan_report+0xb0/0x110 mm/kasan/report.c:595
__asan_report_load1_noabort+0x20/0x2c mm/kasan/report_generic.c:378
ocfs2_xattr_get_type fs/ocfs2/ocfs2_fs.h:1114 [inline]
ocfs2_xattr_list_entries fs/ocfs2/xattr.c:934 [inline]
ocfs2_xattr_ibody_list fs/ocfs2/xattr.c:982 [inline]
ocfs2_listxattr+0x408/0xa74 fs/ocfs2/xattr.c:1044
vfs_listxattr+0xc0/0x128 fs/xattr.c:493
ovl_listxattr+0xd8/0x49c fs/overlayfs/xattrs.c:123
vfs_listxattr fs/xattr.c:493 [inline]
listxattr+0x10c/0x380 fs/xattr.c:924
filename_listxattr fs/xattr.c:958 [inline]
path_listxattrat+0x15c/0x33c fs/xattr.c:988
__do_sys_listxattr fs/xattr.c:1001 [inline]
__se_sys_listxattr fs/xattr.c:998 [inline]
__arm64_sys_listxattr+0x84/0x98 fs/xattr.c:998
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x254 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x5c/0x254 arch/arm64/kernel/entry-common.c:746
el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:765
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffb730e pfn:0x12ba98
flags: 0x5ffc00000000000(node=0|zone=2|lastcpupid=0x7ff)
raw: 05ffc00000000000 fffffdffc3aeb708 fffffdffc3aeb888 0000000000000000
raw: 0000000ffffb730e 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff0000eba97f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff0000eba97f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff0000eba98000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff0000eba98080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff0000eba98100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] ocfs2: validate xattr entry count to prevent use-after-free
Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

The ocfs2_xattr_list_entries() function does not validate the
xh_count field read from the on-disk xattr header. When processing
a corrupted filesystem image, an invalid xh_count value causes the
loop to iterate beyond the bounds of the allocated block. This leads
to out-of-bounds memory access, potentially reaching freed pages and
triggering use-after-free bugs detected by KASAN.

The issue occurs because:
1. xh_count is read directly from disk without validation
2. The loop uses this value to access header->xh_entries[i]
3. When xh_count exceeds the block capacity, entry pointers extend
beyond the allocated memory
4. Accessing these out-of-bounds pointers can reach freed memory

Fix this by validating that xh_count does not exceed the maximum
number of entries that can fit within the block before accessing
the entries array. Calculate the maximum as:
(block_size - header_size) / entry_size

If validation fails, log an error and return -EUCLEAN to indicate
filesystem corruption.

Reported-by: syzbot+ab0ad2...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ab0ad25088673470d2d9
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/ocfs2/xattr.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index d70a20d29e3e..db352df00101 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -928,8 +928,20 @@ static int ocfs2_xattr_list_entries(struct inode *inode,
size_t result = 0;
int i, type, ret;
const char *name;
-
- for (i = 0 ; i < le16_to_cpu(header->xh_count); i++) {
+ u16 count;
+ size_t max_entries;
+ struct super_block *sb = inode->i_sb;
+ count = le16_to_cpu(header->xh_count);
+ max_entries = (sb->s_blocksize - sizeof(struct ocfs2_xattr_header)) /
+ sizeof(struct ocfs2_xattr_entry);
+ if (count > max_entries) {
+ mlog(ML_ERROR,
+ "xattr entry count %u exceeds maximum %zu in inode %llu\n",
+ count, max_entries,
+ (unsigned long long)OCFS2_I(inode)->ip_blkno);
+ return -EUCLEAN;
+ }
+ for (i = 0 ; i < count; i++) {
struct ocfs2_xattr_entry *entry = &header->xh_entries[i];
type = ocfs2_xattr_get_type(entry);
name = (const char *)header +
--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+ab0ad2...@syzkaller.appspotmail.com
Tested-by: syzbot+ab0ad2...@syzkaller.appspotmail.com

Tested on:

commit: e424ed99 Merge remote-tracking branch 'will/for-next/p..

git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

console output: https://syzkaller.appspot.com/x/log.txt?x=14150658580000

kernel config: https://syzkaller.appspot.com/x/.config?x=b8b659f0cab27b22
dashboard link: https://syzkaller.appspot.com/bug?extid=ab0ad25088673470d2d9
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
userspace arch: arm64

patch: https://syzkaller.appspot.com/x/patch.diff?x=1789960a580000

Note: testing is done by a robot and is best-effort only.

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] ocfs2: validate xattr header in ocfs2_validate_inode_block

Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

Add validation of inline xattr header fields when validating inode
blocks to catch corruption early before the inode is used by the
system. This prevents corrupted xattr counts from causing out-of-bounds
access and use-after-free bugs in xattr processing code.

The validation checks:
1. xattr_inline_size does not exceed block size
2. xattr_inline_size is large enough for header structure
3. xattr entry count does not exceed available space

This moves validation to the inode block validation stage, providing
comprehensive protection for all code paths that access inline xattrs.

Reported-by: syzbot+ab0ad2...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ab0ad25088673470d2d9
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---

fs/ocfs2/inode.c | 41 +++++++++++++++++++++++++++++++++++++++++
fs/ocfs2/xattr.c | 16 ++++++++++++++--
2 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
index fcc89856ab95..9d5342b8dbc6 100644
--- a/fs/ocfs2/inode.c
+++ b/fs/ocfs2/inode.c
@@ -1458,6 +1458,47 @@ int ocfs2_validate_inode_block(struct super_block *sb,
(unsigned long long)bh->b_blocknr);
goto bail;
}
+ if (di->i_dyn_features & cpu_to_le16(OCFS2_INLINE_XATTR_FL)) {
+ struct ocfs2_xattr_header *header;
+ u16 xattr_inline_size;
+ u16 xattr_count;
+ size_t max_entries;
+
+ xattr_inline_size = le16_to_cpu(di->i_xattr_inline_size);
+
+ /* Validate inline size is within block bounds */
+ if (xattr_inline_size > sb->s_blocksize) {
+ mlog(ML_ERROR,
+ "xattr inline size %u exceeds block size %lu in inode %llu\n",
+ xattr_inline_size, sb->s_blocksize,
+ (unsigned long long)bh->b_blocknr);
+ goto bail;
+ }
+ /* If there's xattr data, validate it */
+ if (xattr_inline_size > 0) {
+ /* Must be at least big enough for header */
+ if (xattr_inline_size < sizeof(struct ocfs2_xattr_header)) {
+ mlog(ML_ERROR,
+ "xattr inline size %u too small for header in inode %llu\n",
+ xattr_inline_size,
+ (unsigned long long)bh->b_blocknr);
+ goto bail;
+ }
+ header = (struct ocfs2_xattr_header *)
+ ((void *)di + sb->s_blocksize - xattr_inline_size);
+ xattr_count = le16_to_cpu(header->xh_count);
+ max_entries = (xattr_inline_size -
+ sizeof(struct ocfs2_xattr_header)) /
+ sizeof(struct ocfs2_xattr_entry);
+ if (xattr_count > max_entries) {
+ mlog(ML_ERROR,
+ "xattr count %u exceeds maximum %zu in inode %llu\n",
+ xattr_count, max_entries,
+ (unsigned long long)bh->b_blocknr);
+ goto bail;
+ }
+ }
+ }

/*
* Errors after here are fatal.

diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index d70a20d29e3e..db352df00101 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c

@@ -928,8 +928,21 @@ static int ocfs2_xattr_list_entries(struct inode *inode,

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] ocfs2: validate xattr header in ocfs2_validate_inode_block
Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

Add validation of inline xattr header fields when validating inode
blocks to catch corruption early before the inode is used by the
system. This prevents corrupted xattr counts from causing out-of-bounds
access and use-after-free bugs in xattr processing code.

The validation checks:
1. xattr_inline_size does not exceed block size
2. xattr_inline_size is large enough for header structure
3. xattr entry count does not exceed available space

This moves validation to the inode block validation stage, providing
comprehensive protection for all code paths that access inline xattrs.

Reported-by: syzbot+ab0ad2...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ab0ad25088673470d2d9
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/ocfs2/inode.c | 41 +++++++++++++++++++++++++++++++++++++++++

1 file changed, 41 insertions(+)

--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+ab0ad2...@syzkaller.appspotmail.com
Tested-by: syzbot+ab0ad2...@syzkaller.appspotmail.com

Tested on:

commit: e424ed99 Merge remote-tracking branch 'will/for-next/p..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

console output: https://syzkaller.appspot.com/x/log.txt?x=16ac6c12580000

kernel config: https://syzkaller.appspot.com/x/.config?x=b8b659f0cab27b22
dashboard link: https://syzkaller.appspot.com/bug?extid=ab0ad25088673470d2d9
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
userspace arch: arm64

patch: https://syzkaller.appspot.com/x/patch.diff?x=16a1a7cd980000

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: use-after-free Read in ocfs2_listxattr

On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
OCFS2: File system is now read-only.
==================================================================
BUG: KASAN: use-after-free in ocfs2_xattr_get_type fs/ocfs2/ocfs2_fs.h:1114 [inline]
BUG: KASAN: use-after-free in ocfs2_xattr_list_entries fs/ocfs2/xattr.c:934 [inline]
BUG: KASAN: use-after-free in ocfs2_xattr_ibody_list fs/ocfs2/xattr.c:982 [inline]
BUG: KASAN: use-after-free in ocfs2_listxattr+0x408/0xa74 fs/ocfs2/xattr.c:1044

Read of size 1 at addr ffff0000e76a4007 by task syz.0.20/7236

CPU: 1 UID: 0 PID: 7236 Comm: syz.0.20 Not tainted syzkaller #0 PREEMPT

page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffb9581 pfn:0x1276a4
flags: 0x5ffc00000000000(node=0|zone=2|lastcpupid=0x7ff)
raw: 05ffc00000000000 fffffdffc3a50548 fffffdffc39dab88 0000000000000000
raw: 0000000ffffb9581 0000000000000000 00000000ffffffff 0000000000000000

page dumped because: kasan: bad access detected

Memory state around the buggy address:

ffff0000e76a3f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff0000e76a3f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff0000e76a4000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff0000e76a4080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff0000e76a4100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================

Tested on:

commit: e424ed99 Merge remote-tracking branch 'will/for-next/p..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

console output: https://syzkaller.appspot.com/x/log.txt?x=12f30658580000

kernel config: https://syzkaller.appspot.com/x/.config?x=b8b659f0cab27b22
dashboard link: https://syzkaller.appspot.com/bug?extid=ab0ad25088673470d2d9
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
userspace arch: arm64

patch: https://syzkaller.appspot.com/x/patch.diff?x=1566f17c580000

[syzbot]

For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] ocfs2: validate xattr entry count in ocfs2_validate_xattr_block

Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

Add validation of xattr entry count when validating external xattr
blocks to catch corruption early before the block is used by the

system. This prevents corrupted xattr counts from causing out-of-bounds

access and use-after-free bugs when processing xattr entries.

The validation ensures that xh_count does not exceed the maximum number
of entries that can fit within the block. Without this check, a
corrupted filesystem image with an invalid xh_count can cause the code
to iterate beyond the allocated block boundary, potentially accessing
freed memory pages.

The check is added to ocfs2_validate_xattr_block() which is called when
reading xattr blocks from disk, providing protection for all code paths
that subsequently access the xattr entries. This follows the same
pattern as other validation checks in the function.

This patch complements the inline xattr validation added to
ocfs2_validate_inode_block(), providing comprehensive protection for
both inline and external xattr storage.

Reported-by: syzbot+ab0ad2...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ab0ad25088673470d2d9
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---

fs/ocfs2/xattr.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index d70a20d29e3e..3d21f2b9966e 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -470,7 +470,23 @@ static int ocfs2_validate_xattr_block(struct super_block *sb,
trace_ocfs2_validate_xattr_block((unsigned long long)bh->b_blocknr);

BUG_ON(!buffer_uptodate(bh));
-
+ if (!(le16_to_cpu(xb->xb_flags) & OCFS2_XATTR_INDEXED)) {
+ struct ocfs2_xattr_header *header = &xb->xb_attrs.xb_header;

+ u16 xattr_count;
+ size_t max_entries;
+

+ xattr_count = le16_to_cpu(header->xh_count);

+ max_entries = (sb->s_blocksize -
+ offsetof(struct ocfs2_xattr_block, xb_attrs.xb_header) -

+ sizeof(struct ocfs2_xattr_header)) /
+ sizeof(struct ocfs2_xattr_entry);
+ if (xattr_count > max_entries) {

+ return ocfs2_error(sb,
+ "Extended attribute block #%llu has invalid xattr count %u (max %zu)\n",
+ (unsigned long long)bh->b_blocknr,
+ xattr_count, max_entries);
+ }
+ }
/*
* If the ecc fails, we return the error but otherwise
* leave the filesystem running. We know any error is
--
2.43.0

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: use-after-free Read in ocfs2_listxattr

On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
OCFS2: File system is now read-only.
==================================================================
BUG: KASAN: use-after-free in ocfs2_xattr_get_type fs/ocfs2/ocfs2_fs.h:1114 [inline]

BUG: KASAN: use-after-free in ocfs2_xattr_list_entries fs/ocfs2/xattr.c:950 [inline]
BUG: KASAN: use-after-free in ocfs2_xattr_ibody_list fs/ocfs2/xattr.c:998 [inline]
BUG: KASAN: use-after-free in ocfs2_listxattr+0x408/0xa74 fs/ocfs2/xattr.c:1060
Read of size 1 at addr ffff0000ea596007 by task syz.0.17/7218

CPU: 1 UID: 0 PID: 7218 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/03/2025
Call trace:
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:499 (C)
__dump_stack+0x30/0x40 lib/dump_stack.c:94
dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120
print_address_description+0xa8/0x238 mm/kasan/report.c:378
print_report+0x68/0x84 mm/kasan/report.c:482
kasan_report+0xb0/0x110 mm/kasan/report.c:595
__asan_report_load1_noabort+0x20/0x2c mm/kasan/report_generic.c:378
ocfs2_xattr_get_type fs/ocfs2/ocfs2_fs.h:1114 [inline]

ocfs2_xattr_list_entries fs/ocfs2/xattr.c:950 [inline]
ocfs2_xattr_ibody_list fs/ocfs2/xattr.c:998 [inline]
ocfs2_listxattr+0x408/0xa74 fs/ocfs2/xattr.c:1060

vfs_listxattr+0xc0/0x128 fs/xattr.c:493
ovl_listxattr+0xd8/0x49c fs/overlayfs/xattrs.c:123
vfs_listxattr fs/xattr.c:493 [inline]
listxattr+0x10c/0x380 fs/xattr.c:924
filename_listxattr fs/xattr.c:958 [inline]
path_listxattrat+0x15c/0x33c fs/xattr.c:988
__do_sys_listxattr fs/xattr.c:1001 [inline]
__se_sys_listxattr fs/xattr.c:998 [inline]
__arm64_sys_listxattr+0x84/0x98 fs/xattr.c:998
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x254 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x5c/0x254 arch/arm64/kernel/entry-common.c:746
el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:765
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596

The buggy address belongs to the physical page:

page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffa3920 pfn:0x12a596
flags: 0x5ffc00000000000(node=0|zone=2|lastcpupid=0x7ff)
raw: 05ffc00000000000 fffffdffc39b8408 fffffdffc3a3f9c8 0000000000000000
raw: 0000000ffffa3920 0000000000000000 00000000ffffffff 0000000000000000

page dumped because: kasan: bad access detected

Memory state around the buggy address:

ffff0000ea595f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff0000ea595f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff0000ea596000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff0000ea596080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff0000ea596100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

==================================================================


Tested on:

commit: e424ed99 Merge remote-tracking branch 'will/for-next/p..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

console output: https://syzkaller.appspot.com/x/log.txt?x=1594b0b4580000

kernel config: https://syzkaller.appspot.com/x/.config?x=b8b659f0cab27b22
dashboard link: https://syzkaller.appspot.com/bug?extid=ab0ad25088673470d2d9
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
userspace arch: arm64

patch: https://syzkaller.appspot.com/x/patch.diff?x=10c80692580000