[syzbot] [hams?] KASAN: slab-use-after-free Read in ax25_find_cb

3 views
Skip to first unread message

syzbot

unread,
Oct 23, 2025, 8:13:34 AMOct 23
to da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, pab...@redhat.com, syzkall...@googlegroups.com
Hello,

syzbot found the following issue on:

HEAD commit: 250a17e8f955 Merge tag 'erofs-for-6.18-rc3-fixes' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=154a3734580000
kernel config: https://syzkaller.appspot.com/x/.config?x=d1ce99afe6f71855
dashboard link: https://syzkaller.appspot.com/bug?extid=caa052a0958a9146870d
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/f51301069523/disk-250a17e8.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a4671c3f2507/vmlinux-250a17e8.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2b5a3b36a321/bzImage-250a17e8.xz

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

==================================================================
BUG: KASAN: slab-use-after-free in ax25_find_cb+0x3b8/0x3f0 net/ax25/af_ax25.c:237
Read of size 1 at addr ffff888059c704c0 by task syz.6.2733/17200

CPU: 1 UID: 0 PID: 17200 Comm: syz.6.2733 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xcd/0x630 mm/kasan/report.c:482
kasan_report+0xe0/0x110 mm/kasan/report.c:595
ax25_find_cb+0x3b8/0x3f0 net/ax25/af_ax25.c:237
ax25_send_frame+0x157/0xb60 net/ax25/ax25_out.c:55
rose_send_frame+0xcc/0x2c0 net/rose/rose_link.c:106
rose_transmit_restart_request+0x1b8/0x240 net/rose/rose_link.c:198
rose_t0timer_expiry+0x1d/0x150 net/rose/rose_link.c:83
call_timer_fn+0x19a/0x620 kernel/time/timer.c:1747
expire_timers kernel/time/timer.c:1798 [inline]
__run_timers+0x6ef/0x960 kernel/time/timer.c:2372
__run_timer_base kernel/time/timer.c:2384 [inline]
__run_timer_base kernel/time/timer.c:2376 [inline]
run_timer_base+0x114/0x190 kernel/time/timer.c:2393
run_timer_softirq+0x1a/0x40 kernel/time/timer.c:2403
handle_softirqs+0x219/0x8e0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x109/0x170 kernel/softirq.c:723
irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]
sysvec_apic_timer_interrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1052
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0033:0x7fd4a4c68253
Code: 1f 84 00 00 00 00 00 48 8b 70 f8 48 83 e8 08 48 39 f2 72 f3 48 39 c3 73 3e 48 89 33 48 83 c3 08 48 8b 70 f8 48 89 08 48 8b 0b <49> 8b 14 24 eb bf 48 39 f2 72 97 48 39 f0 73 46 49 89 34 24 48 89
RSP: 002b:00007ffd914df840 EFLAGS: 00000212
RAX: 00007fd4a4777648 RBX: 00007fd4a47774b0 RCX: ffffffff8a01d69a
RDX: ffffffff8a01d69a RSI: ffffffff8a01d69a RDI: 00007fd4a47777a0
RBP: 00007fd4a4777358 R08: 00007fd4a4777578 R09: 00007fd4a4fd2000
R10: 00007fd4a43fd008 R11: 000000000000000a R12: 00007fd4a4777350
R13: 0000000000000016 R14: 00007ffd914dfab8 R15: 00007fd4a43fd008
</TASK>

Allocated by task 13773:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:56
kasan_save_track+0x14/0x30 mm/kasan/common.c:77
poison_kmalloc_redzone mm/kasan/common.c:400 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:417
kmalloc_noprof include/linux/slab.h:957 [inline]
rose_add_node net/rose/rose_route.c:109 [inline]
rose_rt_ioctl+0x1c40/0x2580 net/rose/rose_route.c:748
rose_ioctl+0x64d/0x7c0 net/rose/af_rose.c:1381
sock_do_ioctl+0x118/0x280 net/socket.c:1254
sock_ioctl+0x227/0x6b0 net/socket.c:1375
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 17183:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:56
kasan_save_track+0x14/0x30 mm/kasan/common.c:77
__kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:587
kasan_save_free_info mm/kasan/kasan.h:406 [inline]
poison_slab_object mm/kasan/common.c:252 [inline]
__kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284
kasan_slab_free include/linux/kasan.h:234 [inline]
slab_free_hook mm/slub.c:2530 [inline]
slab_free mm/slub.c:6619 [inline]
kfree+0x2b8/0x6d0 mm/slub.c:6826
rose_neigh_put include/net/rose.h:165 [inline]
rose_timer_expiry+0x537/0x630 net/rose/rose_timer.c:183
call_timer_fn+0x19a/0x620 kernel/time/timer.c:1747
expire_timers kernel/time/timer.c:1798 [inline]
__run_timers+0x6ef/0x960 kernel/time/timer.c:2372
__run_timer_base kernel/time/timer.c:2384 [inline]
__run_timer_base kernel/time/timer.c:2376 [inline]
run_timer_base+0x114/0x190 kernel/time/timer.c:2393
run_timer_softirq+0x1a/0x40 kernel/time/timer.c:2403
handle_softirqs+0x219/0x8e0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x109/0x170 kernel/softirq.c:723
irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]
sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1052
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697

The buggy address belongs to the object at ffff888059c70480
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 64 bytes inside of
freed 96-byte region [ffff888059c70480, ffff888059c704e0)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888059c70b00 pfn:0x59c70
flags: 0xfff00000000200(workingset|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000200 ffff88813ffa6280 ffffea0001df33d0 ffffea0000c94410
raw: ffff888059c70b00 000000000020001f 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 5815, tgid 5815 (syz-executor), ts 66851059499, free_ts 66850862508
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1c0/0x230 mm/page_alloc.c:1850
prep_new_page mm/page_alloc.c:1858 [inline]
get_page_from_freelist+0x10a3/0x3a30 mm/page_alloc.c:3884
__alloc_frozen_pages_noprof+0x25f/0x2470 mm/page_alloc.c:5183
alloc_pages_mpol+0x1fb/0x550 mm/mempolicy.c:2416
alloc_slab_page mm/slub.c:3046 [inline]
allocate_slab mm/slub.c:3219 [inline]
new_slab+0x24a/0x360 mm/slub.c:3273
___slab_alloc+0xdc4/0x1ae0 mm/slub.c:4643
__slab_alloc.constprop.0+0x63/0x110 mm/slub.c:4762
__slab_alloc_node mm/slub.c:4838 [inline]
slab_alloc_node mm/slub.c:5260 [inline]
__kmalloc_cache_noprof+0x477/0x780 mm/slub.c:5750
kmalloc_noprof include/linux/slab.h:957 [inline]
kzalloc_noprof include/linux/slab.h:1094 [inline]
class_dir_create_and_add drivers/base/core.c:3223 [inline]
get_device_parent+0x2b1/0x4e0 drivers/base/core.c:3283
device_add+0x1ad/0x1aa0 drivers/base/core.c:3613
netdev_register_kobject+0x1a9/0x3d0 net/core/net-sysfs.c:2358
register_netdevice+0x13dc/0x2270 net/core/dev.c:11294
cfg80211_register_netdevice+0x149/0x340 net/wireless/core.c:1518
ieee80211_if_add+0xc9d/0x1a40 net/mac80211/iface.c:2295
ieee80211_register_hw+0x393b/0x4120 net/mac80211/main.c:1608
mac80211_hwsim_new_radio+0x32d8/0x50b0 drivers/net/wireless/virtual/mac80211_hwsim.c:5803
page last free pid 5815 tgid 5815 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1394 [inline]
__free_frozen_pages+0x7df/0x1160 mm/page_alloc.c:2906
selinux_genfs_get_sid security/selinux/hooks.c:1357 [inline]
inode_doinit_with_dentry+0xacb/0x12e0 security/selinux/hooks.c:1555
selinux_d_instantiate+0x26/0x30 security/selinux/hooks.c:6523
security_d_instantiate+0x142/0x1a0 security/security.c:4148
d_instantiate+0x5c/0x90 fs/dcache.c:1961
__debugfs_create_file+0x286/0x6b0 fs/debugfs/inode.c:459
debugfs_create_file_short+0x41/0x60 fs/debugfs/inode.c:480
add_link_files+0xff/0x120 net/mac80211/debugfs_netdev.c:990
ieee80211_debugfs_add_netdev net/mac80211/debugfs_netdev.c:1011 [inline]
ieee80211_debugfs_recreate_netdev+0xf70/0x17e0 net/mac80211/debugfs_netdev.c:1033
ieee80211_if_add+0x9b9/0x1a40 net/mac80211/iface.c:2269
ieee80211_register_hw+0x393b/0x4120 net/mac80211/main.c:1608
mac80211_hwsim_new_radio+0x32d8/0x50b0 drivers/net/wireless/virtual/mac80211_hwsim.c:5803
hwsim_new_radio_nl+0xba2/0x1330 drivers/net/wireless/virtual/mac80211_hwsim.c:6497
genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115
genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210
netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552

Memory state around the buggy address:
ffff888059c70380: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
ffff888059c70400: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
>ffff888059c70480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff888059c70500: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
ffff888059c70580: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
==================================================================


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

Lizhi Xu

unread,
Oct 23, 2025, 9:32:04 PMOct 23
to syzbot+caa052...@syzkaller.appspotmail.com, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, pab...@redhat.com, syzkall...@googlegroups.com
There is no synchronization between the two timers, rose_t0timer_expiry
and rose_timer_expiry.
rose_timer_expiry() puts the neighbor when the rose state is ROSE_STATE_2.
However, rose_t0timer_expiry() does initiate a restart request on the
neighbor.
When rose_t0timer_expiry() accesses the released neighbor member digipeat,
a UAF is triggered.

To avoid this uaf, when rose_timer_expiry() puts the neighbor, the base
member digipeat is set to NULL.

syzbot reported a slab-use-after-free Read in ax25_find_cb.
BUG: KASAN: slab-use-after-free in ax25_find_cb+0x3b8/0x3f0 net/ax25/af_ax25.c:237
Read of size 1 at addr ffff888059c704c0 by task syz.6.2733/17200

Call Trace:
ax25_find_cb+0x3b8/0x3f0 net/ax25/af_ax25.c:237
ax25_send_frame+0x157/0xb60 net/ax25/ax25_out.c:55
rose_send_frame+0xcc/0x2c0 net/rose/rose_link.c:106
rose_transmit_restart_request+0x1b8/0x240 net/rose/rose_link.c:198
rose_t0timer_expiry+0x1d/0x150 net/rose/rose_link.c:83

Freed by task 17183:
kfree+0x2b8/0x6d0 mm/slub.c:6826
rose_neigh_put include/net/rose.h:165 [inline]
rose_timer_expiry+0x537/0x630 net/rose/rose_timer.c:183
call_timer_fn+0x19a/0x620 kernel/time/timer.c:1747

Fixes: dcb34659028f ("net: rose: split remove and free operations in rose_remove_neigh()")
Reported-by: syzbot+caa052...@syzkaller.appspotmail.com
Signed-off-by: Lizhi Xu <lizh...@windriver.com>
---
include/net/rose.h | 1 +
1 file changed, 1 insertion(+)

diff --git a/include/net/rose.h b/include/net/rose.h
index 2b5491bbf39a..9b0dc81a9589 100644
--- a/include/net/rose.h
+++ b/include/net/rose.h
@@ -163,6 +163,7 @@ static inline void rose_neigh_put(struct rose_neigh *rose_neigh)
if (rose_neigh->ax25)
ax25_cb_put(rose_neigh->ax25);
kfree(rose_neigh->digipeat);
+ rose_neigh->digipeat = NULL;
kfree(rose_neigh);
}
}
--
2.43.0

Kuniyuki Iwashima

unread,
Oct 23, 2025, 11:18:05 PMOct 23
to lizh...@windriver.com, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com, kun...@google.com
From: Lizhi Xu <lizh...@windriver.com>
Date: Fri, 24 Oct 2025 09:31:53 +0800
How does this synchronise with the timer which is going to
touch rose_neigh being freed below ?


> kfree(rose_neigh);

Isn't the problem that we reach here without stopping all timers
or that a timer does not hold refcnt ?


Also, please post a patch in a separate thread so that patchwork
will not be confused.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#resending-after-review

---8<---
The new version of patches should be posted as a separate
thread, not as a reply to the previous posting.
---8<---

Lizhi Xu

unread,
Oct 24, 2025, 5:05:32 AMOct 24
to kun...@google.com, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, lizh...@windriver.com, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
There is no synchronization between the two timers, rose_t0timer_expiry
and rose_timer_expiry.
rose_timer_expiry() puts the neighbor when the rose state is ROSE_STATE_2.
However, rose_t0timer_expiry() does initiate a restart request on the
neighbor.
When rose_t0timer_expiry() accesses the released neighbor member digipeat,
a UAF is triggered.

To avoid this UAF, defer the put operation to rose_t0timer_expiry() and
stop restarting t0timer after putting the neighbor.

When putting the neighbor, set the neighbor to NULL. Setting neighbor to
NULL prevents rose_t0timer_expiry() from restarting t0timer.

syzbot reported a slab-use-after-free Read in ax25_find_cb.
BUG: KASAN: slab-use-after-free in ax25_find_cb+0x3b8/0x3f0 net/ax25/af_ax25.c:237
Read of size 1 at addr ffff888059c704c0 by task syz.6.2733/17200
Call Trace:
ax25_find_cb+0x3b8/0x3f0 net/ax25/af_ax25.c:237
ax25_send_frame+0x157/0xb60 net/ax25/ax25_out.c:55
rose_send_frame+0xcc/0x2c0 net/rose/rose_link.c:106
rose_transmit_restart_request+0x1b8/0x240 net/rose/rose_link.c:198
rose_t0timer_expiry+0x1d/0x150 net/rose/rose_link.c:83

Freed by task 17183:
kfree+0x2b8/0x6d0 mm/slub.c:6826
rose_neigh_put include/net/rose.h:165 [inline]
rose_timer_expiry+0x537/0x630 net/rose/rose_timer.c:183

Fixes: d860d1faa6b2 ("net: rose: convert 'use' field to refcount_t")
Reported-by: syzbot+caa052...@syzkaller.appspotmail.com
Signed-off-by: Lizhi Xu <lizh...@windriver.com>
---
V1 -> V2: Putting the neighbor stops t0timer from automatically starting

include/net/rose.h | 1 +
net/rose/rose_link.c | 5 +++++
2 files changed, 6 insertions(+)

diff --git a/include/net/rose.h b/include/net/rose.h
index 2b5491bbf39a..ecf37c8e24bb 100644
--- a/include/net/rose.h
+++ b/include/net/rose.h
@@ -164,6 +164,7 @@ static inline void rose_neigh_put(struct rose_neigh *rose_neigh)
ax25_cb_put(rose_neigh->ax25);
kfree(rose_neigh->digipeat);
kfree(rose_neigh);
+ rose_neigh = NULL;
}
}

diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
index 7746229fdc8c..524e7935bd02 100644
--- a/net/rose/rose_link.c
+++ b/net/rose/rose_link.c
@@ -43,6 +43,9 @@ void rose_start_ftimer(struct rose_neigh *neigh)

static void rose_start_t0timer(struct rose_neigh *neigh)
{
+ if (!neigh)
+ return;
+
timer_delete(&neigh->t0timer);

neigh->t0timer.function = rose_t0timer_expiry;
@@ -80,10 +83,12 @@ static void rose_t0timer_expiry(struct timer_list *t)
{
struct rose_neigh *neigh = timer_container_of(neigh, t, t0timer);

+ rose_neigh_hold(neigh);
rose_transmit_restart_request(neigh);

neigh->dce_mode = 0;

+ rose_neigh_put(neigh);
rose_start_t0timer(neigh);
}

--
2.43.0

Lizhi Xu

unread,
Oct 24, 2025, 5:06:39 AMOct 24
to kun...@google.com, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, lizh...@windriver.com, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com

Eric Dumazet

unread,
Oct 24, 2025, 5:20:00 AMOct 24
to Lizhi Xu, kun...@google.com, da...@davemloft.net, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
What is the purpose of this added line ?

@rose_neigh is a local variable. Setting it to NULL while this
function no longer uses it is
going to be optimized out by the compiler. Even if not optimized, this
has no effect.


> }
> }
>
> diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
> index 7746229fdc8c..524e7935bd02 100644
> --- a/net/rose/rose_link.c
> +++ b/net/rose/rose_link.c
> @@ -43,6 +43,9 @@ void rose_start_ftimer(struct rose_neigh *neigh)
>
> static void rose_start_t0timer(struct rose_neigh *neigh)
> {
> + if (!neigh)
> + return;

This will never fire. callers would have crashed already it neigh was NULL.

> +
> timer_delete(&neigh->t0timer);
>
> neigh->t0timer.function = rose_t0timer_expiry;
> @@ -80,10 +83,12 @@ static void rose_t0timer_expiry(struct timer_list *t)
> {
> struct rose_neigh *neigh = timer_container_of(neigh, t, t0timer);
>

Can you explain (in a comment) why this is needed ?
What is the precise scenario you want to avoid ?

> + rose_neigh_hold(neigh);
> rose_transmit_restart_request(neigh);
>
> neigh->dce_mode = 0;
>
> + rose_neigh_put(neigh);

I am pretty sure this patch fixes nothing at all.

> rose_start_t0timer(neigh);
> }
>
> --
> 2.43.0
>

Lizhi Xu

unread,
Oct 24, 2025, 5:39:12 AMOct 24
to edum...@google.com, da...@davemloft.net, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, kun...@google.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, lizh...@windriver.com, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
V2 -> V3: add rose_neigh_putex for set rose neigh to NULL

include/net/rose.h | 12 ++++++++++++
net/rose/rose_link.c | 5 +++++
2 files changed, 17 insertions(+)

diff --git a/include/net/rose.h b/include/net/rose.h
index 2b5491bbf39a..33de310ba778 100644
--- a/include/net/rose.h
+++ b/include/net/rose.h
@@ -167,6 +167,18 @@ static inline void rose_neigh_put(struct rose_neigh *rose_neigh)
}
}

+static inline void rose_neigh_putex(struct rose_neigh **roseneigh)
+{
+ struct rose_neigh *rose_neigh = *roseneigh;
+ if (refcount_dec_and_test(&rose_neigh->use)) {
+ if (rose_neigh->ax25)
+ ax25_cb_put(rose_neigh->ax25);
+ kfree(rose_neigh->digipeat);
+ kfree(rose_neigh);
+ *roseneigh = NULL;
+ }
+}
+
/* af_rose.c */
extern ax25_address rose_callsign;
extern int sysctl_rose_restart_request_timeout;
diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
index 7746229fdc8c..334c8cc0876d 100644
--- a/net/rose/rose_link.c
+++ b/net/rose/rose_link.c
@@ -43,6 +43,9 @@ void rose_start_ftimer(struct rose_neigh *neigh)

static void rose_start_t0timer(struct rose_neigh *neigh)
{
+ if (!neigh)
+ return;
+
timer_delete(&neigh->t0timer);

neigh->t0timer.function = rose_t0timer_expiry;
@@ -80,10 +83,12 @@ static void rose_t0timer_expiry(struct timer_list *t)
{
struct rose_neigh *neigh = timer_container_of(neigh, t, t0timer);

+ rose_neigh_hold(neigh);
rose_transmit_restart_request(neigh);

neigh->dce_mode = 0;

+ rose_neigh_putex(&neigh);
rose_start_t0timer(neigh);
}

--
2.43.0

Eric Dumazet

unread,
Oct 24, 2025, 7:50:09 AMOct 24
to Lizhi Xu, da...@davemloft.net, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, kun...@google.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
You have not even compiled this patch.

Also please carefully read Documentation/process/maintainer-netdev.rst

Resending after review
~~~~~~~~~~~~~~~~~~~~~~

Allow at least 24 hours to pass between postings. This will ensure reviewers
from all geographical locations have a chance to chime in. Do not wait
too long (weeks) between postings either as it will make it harder for reviewers
to recall all the context.

Make sure you address all the feedback in your new posting. Do not post a new
version of the code if the discussion about the previous version is still
ongoing, unless directly instructed by a reviewer.

The new version of patches should be posted as a separate thread,
not as a reply to the previous posting. Change log should include a link
to the previous posting (see :ref:`Changes requested`).

Jakub Kicinski

unread,
Oct 24, 2025, 7:58:42 PMOct 24
to Lizhi Xu, kun...@google.com, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, linux...@vger.kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
On Fri, 24 Oct 2025 17:05:21 +0800 Lizhi Xu wrote:
> There is no synchronization between the two timers, rose_t0timer_expiry
> and rose_timer_expiry.
> rose_timer_expiry() puts the neighbor when the rose state is ROSE_STATE_2.
> However, rose_t0timer_expiry() does initiate a restart request on the
> neighbor.

Read what reviewers tell you please.

Kuniyuki already told you not to send patches in reply to existing
threads.

Lizhi Xu

unread,
Oct 24, 2025, 9:48:59 PMOct 24
to edum...@google.com, da...@davemloft.net, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, kun...@google.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, lizh...@windriver.com, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
580K -rw-r--r-- 1 lzx users 578K Oct 24 17:35 net/rose/rose_link.o

Kuniyuki Iwashima

unread,
Oct 24, 2025, 10:18:59 PMOct 24
to Lizhi Xu, edum...@google.com, da...@davemloft.net, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
On Fri, Oct 24, 2025 at 2:39 AM Lizhi Xu <lizh...@windriver.com> wrote:
>
What prevents rose_timer_expiry() from releasing the
last refcnt here ?

The t0timer could be triggered even after that happens.

Lizhi Xu

unread,
Oct 24, 2025, 11:52:00 PMOct 24
to kun...@google.com, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, lizh...@windriver.com, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
The issue reported by syzbot is that rose_t0timer_expiry() is triggered
first, followed by rose_timer_expiry().
Therefore, in rose_t0timer_expiry(), the reference count of neigh is
increased before entering rose_transmit_restart_request() to prevent
neigh from being put in rose_timer_expiry(). Then, in rose_t0timer_expiry(),
neigh is put before executing rose_start_t0timer() and the neigh value is
set to NULL to prevent t0timer restarts.

The case where rose_timer_expiry() is triggered before rose_t0timer_expiry()
is not considered at this time.

Kuniyuki Iwashima

unread,
Oct 25, 2025, 12:25:34 AMOct 25
to Lizhi Xu, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
I don't see how you read that ordering from the report.
https://syzkaller.appspot.com/bug?extid=caa052a0958a9146870d

The only ordering I can find is that kfree() in rose_timer_expiry()
happened before ax25_find_cb () in rose_t0timer_expiry().

> Therefore, in rose_t0timer_expiry(), the reference count of neigh is
> increased before entering rose_transmit_restart_request() to prevent
> neigh from being put in rose_timer_expiry(). Then, in rose_t0timer_expiry(),
> neigh is put before executing rose_start_t0timer() and the neigh value is
> set to NULL to prevent t0timer restarts.
>
> The case where rose_timer_expiry() is triggered before rose_t0timer_expiry()
> is not considered at this time.

So this change just papers over the root cause.

Lizhi Xu

unread,
Oct 25, 2025, 2:46:35 AMOct 25
to kun...@google.com, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, lizh...@windriver.com, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
Here's my understanding: See the two calltraces below.
[1] Line 111 occurs after rose_neigh_put(). Otherwise, accessing
neigh->digipeat would result in a UAF. Therefore, rose_t0timer_expiry()
must be triggered before rose_timer_expiry().

[2] syzbot reports that line 237 generates a UAF when accessing digi->ndigi.

UAF Task1:
rose_t0timer_expiry()->
rose_transmit_restart_request()->
rose_send_frame(.., neigh->digipeat, ..)-> // [1] line 111
ax25_find_cb()->
if (digi != NULL && digi->ndigi != 0) // [2] line 237

Freed neigh Task2:
rose_timer_expiry()->
rose_neigh_put(neigh)->
kfree(neigh)

Kuniyuki Iwashima

unread,
Oct 25, 2025, 3:16:05 AMOct 25
to Lizhi Xu, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
The same question still applies.

What prevents rose_timer_expiry() from releasing the last
refcnt before [1] ?

For example, why is accessing neigh->dev in rose_send_frame()
safe then ?

The commit message mentions that two timers are not
synchronised, but the diff adds no such synchronisation.

Lizhi Xu

unread,
Oct 25, 2025, 3:53:31 AMOct 25
to kun...@google.com, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, lizh...@windriver.com, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
+ rose_neigh_hold(neigh); // [3] This prevents rose_timer_expiry() from putting neigh.
rose_transmit_restart_request(neigh);

neigh->dce_mode = 0;

+ rose_neigh_putex(&neigh); // [4] This prevents t0timer from restarting by setting neigh to NULL.
rose_start_t0timer(neigh);

Kuniyuki Iwashima

unread,
Oct 27, 2025, 1:40:49 PMOct 27
to Lizhi Xu, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
If you ask yourself the same question once more here,
you will notice the fix is broken.

What prevents rose_timer_expiry() from releasing the
last refcnt before rose_neigh_hold() ?

Do you add another rose_neigh_hold() before
rose_neigh_hold() ?

... and the same question applies as long as you are
trying to fix the bug by adding changes in rose_t0timer_expiry().

Lizhi Xu

unread,
Oct 27, 2025, 10:06:10 PMOct 27
to kun...@google.com, da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, linux...@vger.kernel.org, linux-...@vger.kernel.org, lizh...@windriver.com, net...@vger.kernel.org, pab...@redhat.com, syzbot+caa052...@syzkaller.appspotmail.com, syzkall...@googlegroups.com
The UAF issue reported by syzbot is shown below:
CPU0 CPU1
==== ====
rose_t0timer_expiry()
rose_transmit_restart_request()
rose_send_frame()
ax25_send_frame() rose_timer_expiry()
rose_neigh_put()
kfree(neigh)
ax25_find_cb()

My patch calls rose_neigh_hold() before executing rose_transmit_restart_request()
in rose_t0timer_expiry(). It then calls rose_neigh_putex() to release and
set neigh to NULL before executing rose_start_t0timer(). This also prevents
timer0 from restarting.

I think the only questionable part of the patch is the expiration time of
rose_timer. I don't know the expiration time because I don't have a reproducer.
If the value is very small, the result may be different.

syzbot

unread,
Dec 9, 2025, 5:34:31 AM (8 days ago) Dec 9
to da...@davemloft.net, edum...@google.com, ho...@kernel.org, jre...@yaina.de, ku...@kernel.org, kun...@google.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, lizh...@windriver.com, net...@vger.kernel.org, pab...@redhat.com, syzkall...@googlegroups.com
syzbot has found a reproducer for the following issue on:

HEAD commit: c75caf76ed86 Add linux-next specific files for 20251209
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14e91eb4580000
kernel config: https://syzkaller.appspot.com/x/.config?x=b9f785244b836412
dashboard link: https://syzkaller.appspot.com/bug?extid=caa052a0958a9146870d
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15b62a1a580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=144caec2580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/5262ac64cf0f/disk-c75caf76.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ef5f82dd5e01/vmlinux-c75caf76.xz
kernel image: https://storage.googleapis.com/syzbot-assets/1e93d794f3bf/bzImage-c75caf76.xz

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

==================================================================
BUG: KASAN: slab-use-after-free in ax25_find_cb+0x179/0x3a0 net/ax25/af_ax25.c:236
Read of size 8 at addr ffff888077f9da10 by task syz.2.252/6544

CPU: 1 UID: 0 PID: 6544 Comm: syz.2.252 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xca/0x240 mm/kasan/report.c:482
kasan_report+0x118/0x150 mm/kasan/report.c:595
ax25_find_cb+0x179/0x3a0 net/ax25/af_ax25.c:236
rose_link_up net/rose/rose_link.c:129 [inline]
rose_transmit_link+0x16d/0x740 net/rose/rose_link.c:271
rose_write_internal+0x11dc/0x1ac0 net/rose/rose_subr.c:198
rose_connect+0x909/0x10a0 net/rose/af_rose.c:881
__sys_connect_file net/socket.c:2104 [inline]
__sys_connect+0x316/0x440 net/socket.c:2123
__do_sys_connect net/socket.c:2129 [inline]
__se_sys_connect net/socket.c:2126 [inline]
__x64_sys_connect+0x7a/0x90 net/socket.c:2126
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f98cf98f749
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f98d08e5038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00007f98cfbe5fa0 RCX: 00007f98cf98f749
RDX: 0000000000000040 RSI: 0000200000000100 RDI: 0000000000000005
RBP: 00007f98cfa13f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f98cfbe6038 R14: 00007f98cfbe5fa0 R15: 00007fff4c13b338
</TASK>

Allocated by task 6474:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:262 [inline]
__kmalloc_cache_noprof+0x3e2/0x700 mm/slub.c:5776
kmalloc_noprof include/linux/slab.h:957 [inline]
kzalloc_noprof include/linux/slab.h:1094 [inline]
ax25_dev_device_up+0x54/0x600 net/ax25/ax25_dev.c:57
ax25_device_event+0x124/0x630 net/ax25/af_ax25.c:143
notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85
call_netdevice_notifiers_extack net/core/dev.c:2269 [inline]
call_netdevice_notifiers net/core/dev.c:2283 [inline]
__dev_notify_flags+0x18d/0x2e0 net/core/dev.c:-1
netif_change_flags+0xe8/0x1a0 net/core/dev.c:9803
dev_change_flags+0x130/0x260 net/core/dev_api.c:68
dev_ioctl+0x7b4/0x1150 net/core/dev_ioctl.c:842
sock_do_ioctl+0x22c/0x300 net/socket.c:1283
sock_ioctl+0x576/0x790 net/socket.c:1390
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 37:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:234 [inline]
slab_free_hook mm/slub.c:2540 [inline]
slab_free_freelist_hook mm/slub.c:2569 [inline]
slab_free_bulk mm/slub.c:6701 [inline]
kmem_cache_free_bulk+0x3fb/0xdb0 mm/slub.c:7388
kfree_bulk include/linux/slab.h:830 [inline]
kvfree_rcu_bulk+0xe5/0x1f0 mm/slab_common.c:1523
kfree_rcu_work+0xed/0x170 mm/slab_common.c:1601
process_one_work+0x93a/0x15a0 kernel/workqueue.c:3279
process_scheduled_works kernel/workqueue.c:3362 [inline]
worker_thread+0x9b0/0xee0 kernel/workqueue.c:3443
kthread+0x711/0x8a0 kernel/kthread.c:463
ret_from_fork+0x599/0xb30 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246

Last potentially related work creation:
kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
kvfree_call_rcu+0x11b/0x480 mm/slab_common.c:1994
ax25_device_event+0x57e/0x630 net/ax25/af_ax25.c:148
notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85
call_netdevice_notifiers_extack net/core/dev.c:2269 [inline]
call_netdevice_notifiers net/core/dev.c:2283 [inline]
__dev_notify_flags+0x18d/0x2e0 net/core/dev.c:-1
netif_change_flags+0xe8/0x1a0 net/core/dev.c:9803
dev_change_flags+0x130/0x260 net/core/dev_api.c:68
dev_ioctl+0x7b4/0x1150 net/core/dev_ioctl.c:842
sock_do_ioctl+0x22c/0x300 net/socket.c:1283
sock_ioctl+0x576/0x790 net/socket.c:1390
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff888077f9da00
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 16 bytes inside of
freed 256-byte region [ffff888077f9da00, ffff888077f9db00)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x77f9c
head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
anon flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88813fe26b40 0000000000000000 dead000000000001
raw: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
head: 00fff00000000040 ffff88813fe26b40 0000000000000000 dead000000000001
head: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
head: 00fff00000000001 ffffea0001dfe701 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 1, migratetype Unmovable, gfp_mask 0x252800(GFP_NOWAIT|__GFP_NORETRY|__GFP_COMP|__GFP_THISNODE), pid 5886, tgid 5886 (syz-executor), ts 158848081003, free_ts 158761437861
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x234/0x290 mm/page_alloc.c:1846
prep_new_page mm/page_alloc.c:1854 [inline]
get_page_from_freelist+0x2365/0x2440 mm/page_alloc.c:3915
__alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5210
alloc_slab_page mm/slub.c:3077 [inline]
allocate_slab+0x7a/0x3b0 mm/slub.c:3248
new_slab mm/slub.c:3302 [inline]
___slab_alloc+0xf2b/0x1960 mm/slub.c:4656
__slab_alloc+0x65/0x100 mm/slub.c:4779
__slab_alloc_node mm/slub.c:4855 [inline]
slab_alloc_node mm/slub.c:5251 [inline]
__do_kmalloc_node mm/slub.c:5656 [inline]
__kmalloc_node_noprof+0x5d9/0x820 mm/slub.c:5663
kmalloc_array_node_noprof include/linux/slab.h:1075 [inline]
alloc_slab_obj_exts+0x3e/0x100 mm/slub.c:2123
account_slab mm/slub.c:3202 [inline]
allocate_slab+0x1cc/0x3b0 mm/slub.c:3267
new_slab mm/slub.c:3302 [inline]
___slab_alloc+0xf2b/0x1960 mm/slub.c:4656
__slab_alloc+0x65/0x100 mm/slub.c:4779
__slab_alloc_node mm/slub.c:4855 [inline]
slab_alloc_node mm/slub.c:5251 [inline]
__do_kmalloc_node mm/slub.c:5656 [inline]
__kvmalloc_node_noprof+0x6b6/0x920 mm/slub.c:7134
allocate_hook_entries_size net/netfilter/core.c:58 [inline]
nf_hook_entries_grow+0x281/0x720 net/netfilter/core.c:137
__nf_register_net_hook+0x2c9/0x930 net/netfilter/core.c:432
nf_register_net_hook+0xb2/0x190 net/netfilter/core.c:575
nf_register_net_hooks+0x44/0x1b0 net/netfilter/core.c:591
page last free pid 5902 tgid 5902 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1395 [inline]
__free_frozen_pages+0xbc8/0xd30 mm/page_alloc.c:2943
discard_slab mm/slub.c:3346 [inline]
__put_partials+0x146/0x170 mm/slub.c:3886
put_cpu_partial+0x1f2/0x2d0 mm/slub.c:3961
__slab_free+0x288/0x2a0 mm/slub.c:5952
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x97/0x100 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:350
kasan_slab_alloc include/linux/kasan.h:252 [inline]
slab_post_alloc_hook mm/slub.c:4953 [inline]
slab_alloc_node mm/slub.c:5263 [inline]
kmem_cache_alloc_lru_noprof+0x36c/0x6e0 mm/slub.c:5282
__d_alloc+0x37/0x6f0 fs/dcache.c:1730
d_alloc+0x4b/0x190 fs/dcache.c:1809
lookup_one_qstr_excl+0xdc/0x360 fs/namei.c:1743
__start_dirop fs/namei.c:2866 [inline]
start_dirop+0x5c/0x90 fs/namei.c:2875
simple_start_creating+0xc4/0x100 fs/libfs.c:2338
debugfs_start_creating+0xdb/0x1a0 fs/debugfs/inode.c:394
__debugfs_create_file+0x6f/0x400 fs/debugfs/inode.c:428
debugfs_create_file_full+0x3f/0x60 fs/debugfs/inode.c:460

Memory state around the buggy address:
ffff888077f9d900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888077f9d980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888077f9da00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888077f9da80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888077f9db00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


---
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.
Reply all
Reply to author
Forward
0 new messages