public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [syzbot] [hams?] memory leak in nr_add_node
@ 2026-01-15 20:04 syzbot
  2026-01-16  2:19 ` Forwarded: [PATCH] netrom: fix memory leak in nr_add_node() syzbot
                   ` (7 more replies)
  0 siblings, 8 replies; 15+ messages in thread
From: syzbot @ 2026-01-15 20:04 UTC (permalink / raw)
  To: davem, edumazet, horms, kuba, linux-hams, linux-kernel, netdev,
	pabeni, syzkaller-bugs

Hello,

syzbot found the following issue on:

HEAD commit:    ea1013c15392 Merge tag 'bpf-fixes' of git://git.kernel.org..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=147cb184580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d60836e327fd6756
dashboard link: https://syzkaller.appspot.com/bug?extid=3f2d46b6e62b8dd546d3
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13c839b4580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=127cb184580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/5ee91238d53c/disk-ea1013c1.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b8eb70b8203f/vmlinux-ea1013c1.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3aed81c1b1c5/bzImage-ea1013c1.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/6e21e0104490/mount_0.gz

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

BUG: memory leak
unreferenced object 0xffff88811b404b80 (size 64):
  comm "syz.0.17", pid 6071, jiffies 4294944872
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    cc cc cc cc cc cc 02 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc f88ea0ab):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4958 [inline]
    slab_alloc_node mm/slub.c:5263 [inline]
    __kmalloc_cache_noprof+0x3b2/0x570 mm/slub.c:5771
    kmalloc_noprof include/linux/slab.h:957 [inline]
    nr_add_node+0x5bf/0x14b0 net/netrom/nr_route.c:146
    nr_rt_ioctl+0xc32/0x16e0 net/netrom/nr_route.c:651
    nr_ioctl+0x11f/0x1a0 net/netrom/af_netrom.c:1254
    sock_do_ioctl+0x84/0x1a0 net/socket.c:1254
    sock_ioctl+0x149/0x480 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+0xf4/0x140 fs/ioctl.c:583
    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

BUG: memory leak
unreferenced object 0xffff88811b404d00 (size 64):
  comm "syz.0.18", pid 6078, jiffies 4294944884
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    cc cc cc cc cc cc 02 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 8f10725b):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4958 [inline]
    slab_alloc_node mm/slub.c:5263 [inline]
    __kmalloc_cache_noprof+0x3b2/0x570 mm/slub.c:5771
    kmalloc_noprof include/linux/slab.h:957 [inline]
    nr_add_node+0x5bf/0x14b0 net/netrom/nr_route.c:146
    nr_rt_ioctl+0xc32/0x16e0 net/netrom/nr_route.c:651
    nr_ioctl+0x11f/0x1a0 net/netrom/af_netrom.c:1254
    sock_do_ioctl+0x84/0x1a0 net/socket.c:1254
    sock_ioctl+0x149/0x480 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+0xf4/0x140 fs/ioctl.c:583
    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

BUG: memory leak
unreferenced object 0xffff88811b404f80 (size 64):
  comm "syz.0.19", pid 6086, jiffies 4294944897
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    cc cc cc cc cc cc 02 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 14b53e34):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4958 [inline]
    slab_alloc_node mm/slub.c:5263 [inline]
    __kmalloc_cache_noprof+0x3b2/0x570 mm/slub.c:5771
    kmalloc_noprof include/linux/slab.h:957 [inline]
    nr_add_node+0x5bf/0x14b0 net/netrom/nr_route.c:146
    nr_rt_ioctl+0xc32/0x16e0 net/netrom/nr_route.c:651
    nr_ioctl+0x11f/0x1a0 net/netrom/af_netrom.c:1254
    sock_do_ioctl+0x84/0x1a0 net/socket.c:1254
    sock_ioctl+0x149/0x480 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+0xf4/0x140 fs/ioctl.c:583
    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
    do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF


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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Forwarded: [PATCH] netrom: fix memory leak in nr_add_node()
  2026-01-15 20:04 [syzbot] [hams?] memory leak in nr_add_node syzbot
@ 2026-01-16  2:19 ` syzbot
  2026-01-16  3:40 ` syzbot
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 15+ messages in thread
From: syzbot @ 2026-01-16  2:19 UTC (permalink / raw)
  To: linux-kernel, syzkaller-bugs

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

***

Subject: [PATCH] netrom: fix memory leak in nr_add_node()
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When nr_add_node() creates a new neighbor but the route quality is too
low to be added (node already has 3 routes with better quality), the
newly allocated neighbor is never used but remains in the neighbor list
with refcount=1, causing a memory leak.

Fix by checking if the new neighbor was actually used (count > 0) and
removing it from the list if not.

Reported-by: syzbot+3f2d46b6e62b8dd546d3@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 net/netrom/nr_route.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index b94cb2ffbaf8..4b85bacb7f65 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -100,6 +100,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 {
 	struct nr_node  *nr_node;
 	struct nr_neigh *nr_neigh;
+	bool new_neigh = false;
 	int i, found;
 	struct net_device *odev;
 
@@ -172,6 +173,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 			}
 		}
 
+		new_neigh = true;
 		spin_lock_bh(&nr_neigh_list_lock);
 		hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);
 		nr_neigh_hold(nr_neigh);
@@ -279,6 +281,9 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		}
 	}
 
+	if (new_neigh && nr_neigh->count == 0)
+		nr_remove_neigh(nr_neigh);
+
 	nr_neigh_put(nr_neigh);
 	nr_node_unlock(nr_node);
 	nr_node_put(nr_node);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Forwarded: [PATCH] netrom: fix memory leak in nr_add_node()
  2026-01-15 20:04 [syzbot] [hams?] memory leak in nr_add_node syzbot
  2026-01-16  2:19 ` Forwarded: [PATCH] netrom: fix memory leak in nr_add_node() syzbot
@ 2026-01-16  3:40 ` syzbot
  2026-01-16  7:42 ` syzbot
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 15+ messages in thread
From: syzbot @ 2026-01-16  3:40 UTC (permalink / raw)
  To: linux-kernel, syzkaller-bugs

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

***

Subject: [PATCH] netrom: fix memory leak in nr_add_node()
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When nr_add_node() creates a new neighbor but the route quality is too
low to be added (node already has 3 routes with better quality), the
newly allocated neighbor is never used but remains in the neighbor list
with refcount=1, causing a memory leak.

Also fix the same leak in the error path when nr_node allocation fails
after creating a new neighbor.

Fix by tracking whether a new neighbor was allocated and removing it
from the list if it was not used (count == 0) or on allocation failure.

Reported-by: syzbot+3f2d46b6e62b8dd546d3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3f2d46b6e62b8dd546d3
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 net/netrom/nr_route.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index b94cb2ffbaf8..a1591a8f8456 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -100,6 +100,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 {
 	struct nr_node  *nr_node;
 	struct nr_neigh *nr_neigh;
+	bool new_neigh = false;
 	int i, found;
 	struct net_device *odev;
 
@@ -172,6 +173,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 			}
 		}
 
+		new_neigh = true;
 		spin_lock_bh(&nr_neigh_list_lock);
 		hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);
 		nr_neigh_hold(nr_neigh);
@@ -183,8 +185,11 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 
 	if (nr_node == NULL) {
 		if ((nr_node = kmalloc(sizeof(*nr_node), GFP_ATOMIC)) == NULL) {
-			if (nr_neigh)
+			if (nr_neigh) {
+				if (new_neigh)
+					nr_remove_neigh(nr_neigh);
 				nr_neigh_put(nr_neigh);
+			}
 			return -ENOMEM;
 		}
 
@@ -279,6 +284,9 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		}
 	}
 
+	if (new_neigh && nr_neigh->count == 0)
+		nr_remove_neigh(nr_neigh);
+
 	nr_neigh_put(nr_neigh);
 	nr_node_unlock(nr_node);
 	nr_node_put(nr_node);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Forwarded: [PATCH] netrom: fix memory leak in nr_add_node()
  2026-01-15 20:04 [syzbot] [hams?] memory leak in nr_add_node syzbot
  2026-01-16  2:19 ` Forwarded: [PATCH] netrom: fix memory leak in nr_add_node() syzbot
  2026-01-16  3:40 ` syzbot
@ 2026-01-16  7:42 ` syzbot
  2026-01-16  8:28 ` syzbot
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 15+ messages in thread
From: syzbot @ 2026-01-16  7:42 UTC (permalink / raw)
  To: linux-kernel, syzkaller-bugs

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

***

Subject: [PATCH] netrom: fix memory leak in nr_add_node()
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


When nr_add_node() creates a new neighbor but the route quality is too
low to be added (node already has 3 routes with better quality), the
newly allocated neighbor is never used but remains in the neighbor list
with refcount=1, causing a memory leak.

Also fix the same leak in the error path when nr_node allocation fails
after creating a new neighbor.

Fix by tracking whether a new neighbor was allocated and removing it
from the list if it was not used (count == 0) or on allocation failure.

Add debug printk to trace the issue.

Reported-by: syzbot+3f2d46b6e62b8dd546d3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3f2d46b6e62b8dd546d3
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 net/netrom/nr_route.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index b94cb2ffbaf8..b5f6b41e34e5 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -100,9 +100,12 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 {
 	struct nr_node  *nr_node;
 	struct nr_neigh *nr_neigh;
+	bool new_neigh = false;
 	int i, found;
 	struct net_device *odev;
 
+	printk(KERN_ERR "nr_add_node: PATCHED VERSION called\n");
+
 	if ((odev=nr_dev_get(nr)) != NULL) {	/* Can't add routes to ourself */
 		dev_put(odev);
 		return -EINVAL;
@@ -172,6 +175,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 			}
 		}
 
+		new_neigh = true;
 		spin_lock_bh(&nr_neigh_list_lock);
 		hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);
 		nr_neigh_hold(nr_neigh);
@@ -183,8 +187,11 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 
 	if (nr_node == NULL) {
 		if ((nr_node = kmalloc(sizeof(*nr_node), GFP_ATOMIC)) == NULL) {
-			if (nr_neigh)
+			if (nr_neigh) {
+				if (new_neigh)
+					nr_remove_neigh(nr_neigh);
 				nr_neigh_put(nr_neigh);
+			}
 			return -ENOMEM;
 		}
 
@@ -279,6 +286,13 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		}
 	}
 
+	if (new_neigh && nr_neigh->count == 0) {
+		printk(KERN_ERR "nr_add_node: cleaning up unused neighbor\n");
+		nr_remove_neigh(nr_neigh);
+	} else if (new_neigh) {
+		printk(KERN_ERR "nr_add_node: new_neigh used, count=%d\n", nr_neigh->count);
+	}
+
 	nr_neigh_put(nr_neigh);
 	nr_node_unlock(nr_node);
 	nr_node_put(nr_node);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Forwarded: [PATCH] netrom: fix memory leak in nr_add_node()
  2026-01-15 20:04 [syzbot] [hams?] memory leak in nr_add_node syzbot
                   ` (2 preceding siblings ...)
  2026-01-16  7:42 ` syzbot
@ 2026-01-16  8:28 ` syzbot
  2026-01-16  8:59 ` syzbot
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 15+ messages in thread
From: syzbot @ 2026-01-16  8:28 UTC (permalink / raw)
  To: linux-kernel, syzkaller-bugs

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

***

Subject: [PATCH] netrom: fix memory leak in nr_add_node()
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


When nr_add_node() creates a new neighbor but the route quality is too
low to be added (node already has 3 routes with better quality), the
newly allocated neighbor is never used but remains in the neighbor list
with refcount=1, causing a memory leak.

Also fix the same leak in the error path when nr_node allocation fails
after creating a new neighbor.

Fix by tracking whether a new neighbor was allocated and removing it
from the list if it was not used (count == 0) or on allocation failure.

Add debug printk to trace the issue.

Reported-by: syzbot+3f2d46b6e62b8dd546d3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3f2d46b6e62b8dd546d3
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 net/netrom/nr_route.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index b94cb2ffbaf8..b5f6b41e34e5 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -100,9 +100,12 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 {
 	struct nr_node  *nr_node;
 	struct nr_neigh *nr_neigh;
+	bool new_neigh = false;
 	int i, found;
 	struct net_device *odev;
 
+	printk(KERN_ERR "nr_add_node: PATCHED VERSION called\n");
+
 	if ((odev=nr_dev_get(nr)) != NULL) {	/* Can't add routes to ourself */
 		dev_put(odev);
 		return -EINVAL;
@@ -172,6 +175,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 			}
 		}
 
+		new_neigh = true;
 		spin_lock_bh(&nr_neigh_list_lock);
 		hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);
 		nr_neigh_hold(nr_neigh);
@@ -183,8 +187,11 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 
 	if (nr_node == NULL) {
 		if ((nr_node = kmalloc(sizeof(*nr_node), GFP_ATOMIC)) == NULL) {
-			if (nr_neigh)
+			if (nr_neigh) {
+				if (new_neigh)
+					nr_remove_neigh(nr_neigh);
 				nr_neigh_put(nr_neigh);
+			}
 			return -ENOMEM;
 		}
 
@@ -279,6 +286,13 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		}
 	}
 
+	if (new_neigh && nr_neigh->count == 0) {
+		printk(KERN_ERR "nr_add_node: cleaning up unused neighbor\n");
+		nr_remove_neigh(nr_neigh);
+	} else if (new_neigh) {
+		printk(KERN_ERR "nr_add_node: new_neigh used, count=%d\n", nr_neigh->count);
+	}
+
 	nr_neigh_put(nr_neigh);
 	nr_node_unlock(nr_node);
 	nr_node_put(nr_node);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Forwarded: [PATCH] netrom: fix memory leak in nr_add_node()
  2026-01-15 20:04 [syzbot] [hams?] memory leak in nr_add_node syzbot
                   ` (3 preceding siblings ...)
  2026-01-16  8:28 ` syzbot
@ 2026-01-16  8:59 ` syzbot
  2026-01-16  9:39 ` syzbot
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 15+ messages in thread
From: syzbot @ 2026-01-16  8:59 UTC (permalink / raw)
  To: linux-kernel, syzkaller-bugs

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

***

Subject: [PATCH] netrom: fix memory leak in nr_add_node()
Author: kartikey406@gmail.com


#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When nr_add_node() creates a new neighbor but the route quality is too
low to be added (node already has 3 routes with better quality), the
newly allocated neighbor is never used but remains in the neighbor list
with refcount=1, causing a memory leak.

Also fix the same leak in the error path when nr_node allocation fails
after creating a new neighbor.

Fix by tracking whether a new neighbor was allocated and removing it
from the list if it was not used (count == 0) or on allocation failure.

Add debug printk to trace the issue.

Reported-by: syzbot+3f2d46b6e62b8dd546d3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3f2d46b6e62b8dd546d3
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 net/netrom/nr_route.c | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index b94cb2ffbaf8..3cc462c2bef3 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -100,11 +100,16 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 {
 	struct nr_node  *nr_node;
 	struct nr_neigh *nr_neigh;
+	bool new_neigh = false;
 	int i, found;
 	struct net_device *odev;
 
+	printk(KERN_ERR "nr_add_node: entered, quality=%d\n", quality);
+
+
 	if ((odev=nr_dev_get(nr)) != NULL) {	/* Can't add routes to ourself */
 		dev_put(odev);
+		printk(KERN_ERR "nr_add_node: exit EINVAL (route to self)\n");
 		return -EINVAL;
 	}
 
@@ -112,6 +117,8 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 
 	nr_neigh = nr_neigh_get_dev(ax25, dev);
 
+	printk(KERN_ERR "nr_add_node: nr_node=%p, nr_neigh=%p\n", nr_node, nr_neigh);
+
 	/*
 	 * The L2 link to a neighbour has failed in the past
 	 * and now a frame comes from this neighbour. We assume
@@ -172,6 +179,8 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 			}
 		}
 
+		new_neigh = true;
+		printk(KERN_ERR "nr_add_node: created new neighbor\n");
 		spin_lock_bh(&nr_neigh_list_lock);
 		hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);
 		nr_neigh_hold(nr_neigh);
@@ -182,9 +191,14 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		nr_neigh->quality = quality;
 
 	if (nr_node == NULL) {
+		printk(KERN_ERR "nr_add_node: creating new node\n");
 		if ((nr_node = kmalloc(sizeof(*nr_node), GFP_ATOMIC)) == NULL) {
-			if (nr_neigh)
+			printk(KERN_ERR "nr_add_node: node alloc failed\n");
+			if (nr_neigh) {
+				if (new_neigh)
+					nr_remove_neigh(nr_neigh);
 				nr_neigh_put(nr_neigh);
+			}
 			return -ENOMEM;
 		}
 
@@ -209,6 +223,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		spin_unlock_bh(&nr_node_list_lock);
 
 		nr_neigh_put(nr_neigh);
+		printk(KERN_ERR "nr_add_node: exit after new node, neigh count=%d\n", nr_neigh->count);
 		return 0;
 	}
 	nr_node_lock(nr_node);
@@ -225,9 +240,12 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		}
 	}
 
+	printk(KERN_ERR "nr_add_node: found=%d, nr_node->count=%d\n", found, nr_node->count);
+
 	if (!found) {
 		/* We have space at the bottom, slot it in */
 		if (nr_node->count < 3) {
+			printk(KERN_ERR "nr_add_node: adding route (count < 3)\n");
 			nr_node->routes[2] = nr_node->routes[1];
 			nr_node->routes[1] = nr_node->routes[0];
 
@@ -242,6 +260,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		} else {
 			/* It must be better than the worst */
 			if (quality > nr_node->routes[2].quality) {
+				printk(KERN_ERR "nr_add_node: replacing worst route\n");
 				nr_node->routes[2].neighbour->count--;
 				nr_neigh_put(nr_node->routes[2].neighbour);
 
@@ -255,6 +274,9 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 				nr_neigh_hold(nr_neigh);
 				nr_neigh->count++;
 			}
+			else {
+				printk(KERN_ERR "nr_add_node: quality too low, not adding\n");
+			}
 		}
 	}
 
@@ -279,6 +301,15 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		}
 	}
 
+	printk(KERN_ERR "nr_add_node: end, new_neigh=%d, count=%d\n", new_neigh, nr_neigh->count);
+
+	if (new_neigh && nr_neigh->count == 0) {
+		printk(KERN_ERR "nr_add_node: end, new_neigh=%d, count=%d\n", new_neigh, nr_neigh->count);
+		nr_remove_neigh(nr_neigh);
+	} else if (new_neigh) {
+		printk(KERN_ERR "nr_add_node: new_neigh used, count=%d\n", nr_neigh->count);
+	}
+
 	nr_neigh_put(nr_neigh);
 	nr_node_unlock(nr_node);
 	nr_node_put(nr_node);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Forwarded: [PATCH] netrom: fix memory leak in nr_add_node()
  2026-01-15 20:04 [syzbot] [hams?] memory leak in nr_add_node syzbot
                   ` (4 preceding siblings ...)
  2026-01-16  8:59 ` syzbot
@ 2026-01-16  9:39 ` syzbot
  2026-01-16 12:51 ` syzbot
  2026-01-17 14:26 ` Testing for netrom: fix memory leak in nr_add_node Prithvi Tambewagh
  7 siblings, 0 replies; 15+ messages in thread
From: syzbot @ 2026-01-16  9:39 UTC (permalink / raw)
  To: linux-kernel, syzkaller-bugs

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

***

Subject: [PATCH] netrom: fix memory leak in nr_add_node()
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master



When nr_add_node() creates a new neighbor but the route quality is too
low to be added (node already has 3 routes with better quality), the
newly allocated neighbor is never used but remains in the neighbor list
with refcount=1, causing a memory leak.

Also fix the same leak in the error path when nr_node allocation fails
after creating a new neighbor.

Fix by tracking whether a new neighbor was allocated and removing it
from the list if it was not used (count == 0) or on allocation failure.

Add debug printk to trace device notifier events.

Reported-by: syzbot+3f2d46b6e62b8dd546d3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3f2d46b6e62b8dd546d3
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 net/netrom/af_netrom.c |  3 +++
 net/netrom/nr_route.c  | 33 ++++++++++++++++++++++++++++++++-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
index 5ed1a71ceec1..ecb47c8e2f0e 100644
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -116,11 +116,14 @@ static int nr_device_event(struct notifier_block *this, unsigned long event, voi
 {
 	struct net_device *dev = netdev_notifier_info_to_dev(ptr);
 
+	printk(KERN_ERR "nr_device_event: dev=%s event=%lu\n", dev->name, event);
+
 	if (!net_eq(dev_net(dev), &init_net))
 		return NOTIFY_DONE;
 
 	if (event != NETDEV_DOWN)
 		return NOTIFY_DONE;
+	printk(KERN_ERR "nr_device_event: calling nr_rt_device_down for %s\n", dev->name);
 
 	nr_kill_by_device(dev);
 	nr_rt_device_down(dev);
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index b94cb2ffbaf8..3cc462c2bef3 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -100,11 +100,16 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 {
 	struct nr_node  *nr_node;
 	struct nr_neigh *nr_neigh;
+	bool new_neigh = false;
 	int i, found;
 	struct net_device *odev;
 
+	printk(KERN_ERR "nr_add_node: entered, quality=%d\n", quality);
+
+
 	if ((odev=nr_dev_get(nr)) != NULL) {	/* Can't add routes to ourself */
 		dev_put(odev);
+		printk(KERN_ERR "nr_add_node: exit EINVAL (route to self)\n");
 		return -EINVAL;
 	}
 
@@ -112,6 +117,8 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 
 	nr_neigh = nr_neigh_get_dev(ax25, dev);
 
+	printk(KERN_ERR "nr_add_node: nr_node=%p, nr_neigh=%p\n", nr_node, nr_neigh);
+
 	/*
 	 * The L2 link to a neighbour has failed in the past
 	 * and now a frame comes from this neighbour. We assume
@@ -172,6 +179,8 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 			}
 		}
 
+		new_neigh = true;
+		printk(KERN_ERR "nr_add_node: created new neighbor\n");
 		spin_lock_bh(&nr_neigh_list_lock);
 		hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);
 		nr_neigh_hold(nr_neigh);
@@ -182,9 +191,14 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		nr_neigh->quality = quality;
 
 	if (nr_node == NULL) {
+		printk(KERN_ERR "nr_add_node: creating new node\n");
 		if ((nr_node = kmalloc(sizeof(*nr_node), GFP_ATOMIC)) == NULL) {
-			if (nr_neigh)
+			printk(KERN_ERR "nr_add_node: node alloc failed\n");
+			if (nr_neigh) {
+				if (new_neigh)
+					nr_remove_neigh(nr_neigh);
 				nr_neigh_put(nr_neigh);
+			}
 			return -ENOMEM;
 		}
 
@@ -209,6 +223,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		spin_unlock_bh(&nr_node_list_lock);
 
 		nr_neigh_put(nr_neigh);
+		printk(KERN_ERR "nr_add_node: exit after new node, neigh count=%d\n", nr_neigh->count);
 		return 0;
 	}
 	nr_node_lock(nr_node);
@@ -225,9 +240,12 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		}
 	}
 
+	printk(KERN_ERR "nr_add_node: found=%d, nr_node->count=%d\n", found, nr_node->count);
+
 	if (!found) {
 		/* We have space at the bottom, slot it in */
 		if (nr_node->count < 3) {
+			printk(KERN_ERR "nr_add_node: adding route (count < 3)\n");
 			nr_node->routes[2] = nr_node->routes[1];
 			nr_node->routes[1] = nr_node->routes[0];
 
@@ -242,6 +260,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		} else {
 			/* It must be better than the worst */
 			if (quality > nr_node->routes[2].quality) {
+				printk(KERN_ERR "nr_add_node: replacing worst route\n");
 				nr_node->routes[2].neighbour->count--;
 				nr_neigh_put(nr_node->routes[2].neighbour);
 
@@ -255,6 +274,9 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 				nr_neigh_hold(nr_neigh);
 				nr_neigh->count++;
 			}
+			else {
+				printk(KERN_ERR "nr_add_node: quality too low, not adding\n");
+			}
 		}
 	}
 
@@ -279,6 +301,15 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		}
 	}
 
+	printk(KERN_ERR "nr_add_node: end, new_neigh=%d, count=%d\n", new_neigh, nr_neigh->count);
+
+	if (new_neigh && nr_neigh->count == 0) {
+		printk(KERN_ERR "nr_add_node: end, new_neigh=%d, count=%d\n", new_neigh, nr_neigh->count);
+		nr_remove_neigh(nr_neigh);
+	} else if (new_neigh) {
+		printk(KERN_ERR "nr_add_node: new_neigh used, count=%d\n", nr_neigh->count);
+	}
+
 	nr_neigh_put(nr_neigh);
 	nr_node_unlock(nr_node);
 	nr_node_put(nr_node);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Forwarded: [PATCH] netrom: fix memory leak in nr_add_node()
  2026-01-15 20:04 [syzbot] [hams?] memory leak in nr_add_node syzbot
                   ` (5 preceding siblings ...)
  2026-01-16  9:39 ` syzbot
@ 2026-01-16 12:51 ` syzbot
  2026-01-17 14:26 ` Testing for netrom: fix memory leak in nr_add_node Prithvi Tambewagh
  7 siblings, 0 replies; 15+ messages in thread
From: syzbot @ 2026-01-16 12:51 UTC (permalink / raw)
  To: linux-kernel, syzkaller-bugs

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

***

Subject: [PATCH] netrom: fix memory leak in nr_add_node()
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

When nr_add_node() creates a new neighbor but the route quality is too
low to be added (node already has 3 routes with better quality), the
newly allocated neighbor is never used but remains in the neighbor list
with refcount=1, causing a memory leak.

Also fix the same leak in the error path when nr_node allocation fails
after creating a new neighbor.

Fix by tracking whether a new neighbor was allocated and removing it
from the list if it was not used (count == 0) or on allocation failure.

Add debug printk to trace nr_rt_device_down cleanup.

Reported-by: syzbot+3f2d46b6e62b8dd546d3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3f2d46b6e62b8dd546d3
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 net/netrom/af_netrom.c |  3 +++
 net/netrom/nr_route.c  | 39 ++++++++++++++++++++++++++++++++++++++-
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
index 5ed1a71ceec1..ecb47c8e2f0e 100644
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -116,11 +116,14 @@ static int nr_device_event(struct notifier_block *this, unsigned long event, voi
 {
 	struct net_device *dev = netdev_notifier_info_to_dev(ptr);
 
+	printk(KERN_ERR "nr_device_event: dev=%s event=%lu\n", dev->name, event);
+
 	if (!net_eq(dev_net(dev), &init_net))
 		return NOTIFY_DONE;
 
 	if (event != NETDEV_DOWN)
 		return NOTIFY_DONE;
+	printk(KERN_ERR "nr_device_event: calling nr_rt_device_down for %s\n", dev->name);
 
 	nr_kill_by_device(dev);
 	nr_rt_device_down(dev);
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index b94cb2ffbaf8..1fac8c6e5c26 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -100,11 +100,16 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 {
 	struct nr_node  *nr_node;
 	struct nr_neigh *nr_neigh;
+	bool new_neigh = false;
 	int i, found;
 	struct net_device *odev;
 
+	printk(KERN_ERR "nr_add_node: entered, quality=%d\n", quality);
+
+
 	if ((odev=nr_dev_get(nr)) != NULL) {	/* Can't add routes to ourself */
 		dev_put(odev);
+		printk(KERN_ERR "nr_add_node: exit EINVAL (route to self)\n");
 		return -EINVAL;
 	}
 
@@ -112,6 +117,8 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 
 	nr_neigh = nr_neigh_get_dev(ax25, dev);
 
+	printk(KERN_ERR "nr_add_node: nr_node=%p, nr_neigh=%p\n", nr_node, nr_neigh);
+
 	/*
 	 * The L2 link to a neighbour has failed in the past
 	 * and now a frame comes from this neighbour. We assume
@@ -172,6 +179,8 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 			}
 		}
 
+		new_neigh = true;
+		printk(KERN_ERR "nr_add_node: created new neighbor\n");
 		spin_lock_bh(&nr_neigh_list_lock);
 		hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);
 		nr_neigh_hold(nr_neigh);
@@ -182,9 +191,14 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		nr_neigh->quality = quality;
 
 	if (nr_node == NULL) {
+		printk(KERN_ERR "nr_add_node: creating new node\n");
 		if ((nr_node = kmalloc(sizeof(*nr_node), GFP_ATOMIC)) == NULL) {
-			if (nr_neigh)
+			printk(KERN_ERR "nr_add_node: node alloc failed\n");
+			if (nr_neigh) {
+				if (new_neigh)
+					nr_remove_neigh(nr_neigh);
 				nr_neigh_put(nr_neigh);
+			}
 			return -ENOMEM;
 		}
 
@@ -209,6 +223,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		spin_unlock_bh(&nr_node_list_lock);
 
 		nr_neigh_put(nr_neigh);
+		printk(KERN_ERR "nr_add_node: exit after new node, neigh count=%d\n", nr_neigh->count);
 		return 0;
 	}
 	nr_node_lock(nr_node);
@@ -225,9 +240,12 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		}
 	}
 
+	printk(KERN_ERR "nr_add_node: found=%d, nr_node->count=%d\n", found, nr_node->count);
+
 	if (!found) {
 		/* We have space at the bottom, slot it in */
 		if (nr_node->count < 3) {
+			printk(KERN_ERR "nr_add_node: adding route (count < 3)\n");
 			nr_node->routes[2] = nr_node->routes[1];
 			nr_node->routes[1] = nr_node->routes[0];
 
@@ -242,6 +260,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		} else {
 			/* It must be better than the worst */
 			if (quality > nr_node->routes[2].quality) {
+				printk(KERN_ERR "nr_add_node: replacing worst route\n");
 				nr_node->routes[2].neighbour->count--;
 				nr_neigh_put(nr_node->routes[2].neighbour);
 
@@ -255,6 +274,9 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 				nr_neigh_hold(nr_neigh);
 				nr_neigh->count++;
 			}
+			else {
+				printk(KERN_ERR "nr_add_node: quality too low, not adding\n");
+			}
 		}
 	}
 
@@ -279,6 +301,15 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		}
 	}
 
+	printk(KERN_ERR "nr_add_node: end, new_neigh=%d, count=%d\n", new_neigh, nr_neigh->count);
+
+	if (new_neigh && nr_neigh->count == 0) {
+		printk(KERN_ERR "nr_add_node: end, new_neigh=%d, count=%d\n", new_neigh, nr_neigh->count);
+		nr_remove_neigh(nr_neigh);
+	} else if (new_neigh) {
+		printk(KERN_ERR "nr_add_node: new_neigh used, count=%d\n", nr_neigh->count);
+	}
+
 	nr_neigh_put(nr_neigh);
 	nr_node_unlock(nr_node);
 	nr_node_put(nr_node);
@@ -511,14 +542,19 @@ void nr_rt_device_down(struct net_device *dev)
 	struct nr_node  *t;
 	int i;
 
+	printk(KERN_ERR "nr_rt_device_down: start for dev=%s (%p)\n", dev->name, dev);
+
 	spin_lock_bh(&nr_neigh_list_lock);
 	nr_neigh_for_each_safe(s, nodet, &nr_neigh_list) {
+		printk(KERN_ERR "nr_rt_device_down: checking neigh dev=%p vs %p\n", s->dev, dev);
 		if (s->dev == dev) {
+			printk(KERN_ERR "nr_rt_device_down: MATCH - removing neigh\n");
 			spin_lock_bh(&nr_node_list_lock);
 			nr_node_for_each_safe(t, node2t, &nr_node_list) {
 				nr_node_lock(t);
 				for (i = 0; i < t->count; i++) {
 					if (t->routes[i].neighbour == s) {
+						printk(KERN_ERR "nr_rt_device_down: removing route %d\n", i);
 						t->count--;
 
 						switch (i) {
@@ -543,6 +579,7 @@ void nr_rt_device_down(struct net_device *dev)
 			nr_remove_neigh_locked(s);
 		}
 	}
+	printk(KERN_ERR "nr_rt_device_down: done\n");
 	spin_unlock_bh(&nr_neigh_list_lock);
 }
 
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Testing for netrom: fix memory leak in nr_add_node
  2026-01-15 20:04 [syzbot] [hams?] memory leak in nr_add_node syzbot
                   ` (6 preceding siblings ...)
  2026-01-16 12:51 ` syzbot
@ 2026-01-17 14:26 ` Prithvi Tambewagh
  2026-01-17 17:00   ` [syzbot] [hams?] " syzbot
  2026-01-19 21:06   ` Testing for netrom: fix " F6BVP
  7 siblings, 2 replies; 15+ messages in thread
From: Prithvi Tambewagh @ 2026-01-17 14:26 UTC (permalink / raw)
  To: syzbot+3f2d46b6e62b8dd546d3, davem, edumazet, horms, kuba, pabeni
  Cc: linux-hams, linux-kernel, netdev, syzkaller-bugs,
	Prithvi Tambewagh

#syz test upstream ea1013c1539270e372fc99854bc6e4d94eaeff66

Signed-off-by: Prithvi Tambewagh <activprithvi@gmail.com>
---
 net/netrom/nr_route.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index b94cb2ffbaf8..20da41888151 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -176,6 +176,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		hlist_add_head(&nr_neigh->neigh_node, &nr_neigh_list);
 		nr_neigh_hold(nr_neigh);
 		spin_unlock_bh(&nr_neigh_list_lock);
+		nr_neigh_put(nr_neigh);
 	}
 
 	if (quality != 0 && ax25cmp(nr, ax25) == 0 && !nr_neigh->locked)

base-commit: ea1013c1539270e372fc99854bc6e4d94eaeff66
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [syzbot] [hams?] memory leak in nr_add_node
  2026-01-17 14:26 ` Testing for netrom: fix memory leak in nr_add_node Prithvi Tambewagh
@ 2026-01-17 17:00   ` syzbot
  2026-01-19 21:06   ` Testing for netrom: fix " F6BVP
  1 sibling, 0 replies; 15+ messages in thread
From: syzbot @ 2026-01-17 17:00 UTC (permalink / raw)
  To: activprithvi, davem, edumazet, horms, kuba, linux-hams,
	linux-kernel, netdev, pabeni, syzkaller-bugs

Hello,

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

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

Tested on:

commit:         ea1013c1 Merge tag 'bpf-fixes' of git://git.kernel.org..
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=1740b522580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d60836e327fd6756
dashboard link: https://syzkaller.appspot.com/bug?extid=3f2d46b6e62b8dd546d3
compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=15da13fc580000

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Testing for netrom: fix memory leak in nr_add_node
  2026-01-17 14:26 ` Testing for netrom: fix memory leak in nr_add_node Prithvi Tambewagh
  2026-01-17 17:00   ` [syzbot] [hams?] " syzbot
@ 2026-01-19 21:06   ` F6BVP
  2026-01-20  3:37     ` David Ranch
  1 sibling, 1 reply; 15+ messages in thread
From: F6BVP @ 2026-01-19 21:06 UTC (permalink / raw)
  To: activprithvi
  Cc: davem, edumazet, horms, kuba, linux-hams, linux-kernel, netdev,
	pabeni, syzbot+3f2d46b6e62b8dd546d3, syzkaller-bugs


Proposed patch is lethal to netrom module and kernel causing a reboot 
after a few minutes running ROSE / FPAC node f6bvp.

Bernard, f6bvp


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Testing for netrom: fix memory leak in nr_add_node
  2026-01-19 21:06   ` Testing for netrom: fix " F6BVP
@ 2026-01-20  3:37     ` David Ranch
  2026-01-20 16:00       ` Prithvi
  0 siblings, 1 reply; 15+ messages in thread
From: David Ranch @ 2026-01-20  3:37 UTC (permalink / raw)
  To: F6BVP, activprithvi
  Cc: davem, edumazet, horms, kuba, linux-hams, linux-kernel, netdev,
	pabeni, syzbot+3f2d46b6e62b8dd546d3, syzkaller-bugs


Thanks for catching that Bernard and I sure wish kernel committers would 
test their code before committing it! Does the kernel show any sort of 
diagnostic information before it resets?  An oops on the serial console, 
etc?

--David
KI6ZHD


On 01/19/2026 01:06 PM, F6BVP wrote:
>
> Proposed patch is lethal to netrom module and kernel causing a reboot 
> after a few minutes running ROSE / FPAC node f6bvp.
>
> Bernard, f6bvp
>


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Testing for netrom: fix memory leak in nr_add_node
  2026-01-20  3:37     ` David Ranch
@ 2026-01-20 16:00       ` Prithvi
  2026-01-20 21:02         ` F6BVP
  0 siblings, 1 reply; 15+ messages in thread
From: Prithvi @ 2026-01-20 16:00 UTC (permalink / raw)
  To: dranch, f6bvp
  Cc: davem, edumazet, horms, kuba, linux-hams, linux-kernel, netdev,
	pabeni, syzbot+3f2d46b6e62b8dd546d3, syzkaller-bugs

On Mon, Jan 19, 2026 at 07:37:07PM -0800, David Ranch wrote:
> 
> Thanks for catching that Bernard and I sure wish kernel committers would
> test their code before committing it! Does the kernel show any sort of
> diagnostic information before it resets?  An oops on the serial console,
> etc?
> 
> --David
> KI6ZHD
> 
> 
> On 01/19/2026 01:06 PM, F6BVP wrote:
> > 
> > Proposed patch is lethal to netrom module and kernel causing a reboot
> > after a few minutes running ROSE / FPAC node f6bvp.
> > 
> > Bernard, f6bvp
> > 
> 

Hello Bernard and David,

Thank you very much for your feedback. I sincerely apologize for the
instability caused due to this patch. I take this instability very 
seriously.

Unfortunately I am on a low-end backup system right now which does not have 
resources to build or boot custom kernels effectively, locally. That's why, 
it has been difficult for me to test the patch locally due to which I have 
been relying on syzbot for testing. I am grateful for your feedback by 
testing that patch on your setup.

I will work on investigating further why the kernel isn't stable with this
patch and try to create a better fix for this bug. 

Thanks a lot Bernard for testing this patch. In case you get any crash 
dump or similar information, it would be very helpful to understand the issue 
and fix it. 

Thank you very much and best regards,
Prithvi


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Testing for netrom: fix memory leak in nr_add_node
  2026-01-20 16:00       ` Prithvi
@ 2026-01-20 21:02         ` F6BVP
  2026-01-22 17:27           ` Prithvi
  0 siblings, 1 reply; 15+ messages in thread
From: F6BVP @ 2026-01-20 21:02 UTC (permalink / raw)
  To: Prithvi, dranch
  Cc: davem, edumazet, horms, kuba, linux-hams, linux-kernel, netdev,
	pabeni, syzbot+3f2d46b6e62b8dd546d3, syzkaller-bugs

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]



Le 20/01/2026 à 17:00, Prithvi a écrit :
> Hello Bernard and David,
> 
> Thank you very much for your feedback. I sincerely apologize for the
> instability caused due to this patch. I take this instability very
> seriously.
> 
> Unfortunately I am on a low-end backup system right now which does not have
> resources to build or boot custom kernels effectively, locally. That's why,
> it has been difficult for me to test the patch locally due to which I have
> been relying on syzbot for testing. I am grateful for your feedback by
> testing that patch on your setup.
> 
> I will work on investigating further why the kernel isn't stable with this
> patch and try to create a better fix for this bug.
> 
> Thanks a lot Bernard for testing this patch. In case you get any crash
> dump or similar information, it would be very helpful to understand the issue
> and fix it.
> 
> Thank you very much and best regards,
> Prithvi
> 
Hi Prithvi,

Your effort in improving netrom protocole AX25 is appreciated.
I reactivated netconsole between my two ROSE FPAC nodes machines in 
order to catch kernel panic triggered by adding your line of patch.

Regards,

Bernard, f6bvp

[-- Attachment #2: netconsole.txt --]
[-- Type: text/plain, Size: 14435 bytes --]



6,1306,1249564798,-;NET: Registered PF_AX25 protocol family
6,1307,1249581517,-;mkiss: AX.25 Multikiss, Hans Albas PE1AYX
6,1308,1249627212,-;NET: Registered PF_ROSE protocol family
6,1309,1252718950,-;mkiss: AX.25 Multikiss, Hans Albas PE1AYX
6,1310,1252721666,-;mkiss: ax0: crc mode is auto.
6,1311,1254808312,-;NET: Registered PF_NETROM protocol family
6,1312,1266780331,-;mkiss: ax0: Trying crc-smack
6,1313,1266782411,-;mkiss: ax0: Trying crc-flexnet
3,1314,2553484762,-;==================================================================
3,1315,2553485598,-;BUG: KASAN: slab-use-after-free in nr_rt_ioctl+0x2073/0x2d20 [netrom]
3,1316,2553486313,-;Read of size 2 at addr ffff88811bc50e32 by task netromd/4776
3,1317,2553486860,-;
3,1318,2553487398,-;CPU: 1 UID: 0 PID: 4776 Comm: netromd Not tainted 6.19.0-rc5-f6bvp+ #50 PREEMPT(voluntary) 
3,1319,2553487403,-;Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020
3,1320,2553487406,-;Call Trace:
3,1321,2553487407,-; <TASK>
3,1322,2553487409,-; dump_stack_lvl+0x5f/0x90
3,1323,2553487415,-; print_report+0x171/0x4f5
3,1324,2553487420,-; ? __pfx__raw_spin_lock_irqsave+0x10/0x10
3,1325,2553487425,-; ? sched_clock_noinstr+0x9/0x10
3,1326,2553487430,-; ? kasan_complete_mode_report_info+0x88/0x230
3,1327,2553487437,-; kasan_report+0xf2/0x130
3,1328,2553487440,-; ? nr_rt_ioctl+0x2073/0x2d20 [netrom]
3,1329,2553487447,-; ? nr_rt_ioctl+0x2073/0x2d20 [netrom]
3,1330,2553487453,-; __asan_report_load2_noabort+0x14/0x30
3,1331,2553487457,-; nr_rt_ioctl+0x2073/0x2d20 [netrom]
3,1332,2553487465,-; ? __pfx_nr_rt_ioctl+0x10/0x10 [netrom]
3,1333,2553487471,-; ? try_to_merge_with_ksm_page+0x170/0x2b0
3,1334,2553487476,-; ? apparmor_capable+0x159/0x470
3,1335,2553487482,-; ? security_capable+0x95/0x1c0
3,1336,2553487488,-; nr_ioctl+0x12d/0x290 [netrom]
3,1337,2553487493,-; ? alloc_empty_file+0xad/0x160
3,1338,2553487498,-; sock_do_ioctl+0x114/0x230
3,1339,2553487504,-; ? alloc_file_pseudo+0x163/0x230
3,1340,2553487507,-; ? __pfx_sock_do_ioctl+0x10/0x10
3,1341,2553487511,-; ? __pfx_alloc_file_pseudo+0x10/0x10
3,1342,2553487514,-; ? security_socket_post_create+0x78/0x200
3,1343,2553487519,-; ? __pfx_do_vfs_ioctl+0x10/0x10
3,1344,2553487525,-; ? sock_alloc_file+0xe2/0x220
3,1345,2553487529,-; sock_ioctl+0x3a6/0x640
3,1346,2553487532,-; ? __pfx_fput_close_sync+0x10/0x10
3,1347,2553487535,-; ? __pfx___sys_socket+0x10/0x10
3,1348,2553487538,-; ? __pfx_sock_ioctl+0x10/0x10
3,1349,2553487541,-; ? __kasan_check_read+0x11/0x20
3,1350,2553487545,-; ? hook_file_ioctl+0x10/0x20
3,1351,2553487550,-; __x64_sys_ioctl+0x147/0x1e0
3,1352,2553487554,-; x64_sys_call+0x1060/0x2360
3,1353,2553487558,-; do_syscall_64+0x82/0x5d0
3,1354,2553487561,-; ? __fput+0x554/0xaa0
3,1355,2553487565,-; ? fput_close_sync+0xe3/0x1b0
3,1356,2553487569,-; ? __pfx_fput_close_sync+0x10/0x10
3,1357,2553487573,-; ? __kasan_check_read+0x11/0x20
3,1358,2553487576,-; ? fpregs_assert_state_consistent+0x5c/0x100
3,1359,2553487581,-; ? do_syscall_64+0xbf/0x5d0
3,1360,2553487584,-; ? ksys_read+0x104/0x240
3,1361,2553487587,-; ? __pfx_ksys_read+0x10/0x10
3,1362,2553487591,-; ? __kasan_check_read+0x11/0x20
3,1363,2553487595,-; ? fpregs_assert_state_consistent+0x5c/0x100
3,1364,2553487598,-; ? do_syscall_64+0xbf/0x5d0
3,1365,2553487601,-; ? exc_page_fault+0x95/0x100
3,1366,2553487605,-; entry_SYSCALL_64_after_hwframe+0x76/0x7e
3,1367,2553487608,-;RIP: 0033:0x77cecd73287d
3,1368,2553487612,-;Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
3,1369,2553487615,-;RSP: 002b:00007fff83cb9d10 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
3,1370,2553487620,-;RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 000077cecd73287d
3,1371,2553487623,-;RDX: 00007fff83cb9dcc RSI: 00000000000089e2 RDI: 0000000000000005
3,1372,2553487625,-;RBP: 00007fff83cb9d60 R08: 0000000000000000 R09: 0000000000000000
3,1373,2553487627,-;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000078
3,1374,2553487630,-;R13: 0000601de2d57a60 R14: 00007fff83cb9ef0 R15: 0000601dc3550159
3,1375,2553487634,-; </TASK>
3,1376,2553487635,-;
3,1377,2553522861,-;Allocated by task 4511 on cpu 3 at 1255.067864s:
4,1378,2553523540,-; kasan_save_stack+0x3a/0x70
4,1379,2553524231,-; kasan_save_track+0x18/0x70
4,1380,2553524918,-; kasan_save_alloc_info+0x39/0x60
4,1381,2553525593,-; __kasan_kmalloc+0xa9/0xd0
4,1382,2553526563,-; __kmalloc_cache_noprof+0x20b/0x5b0
4,1383,2553527209,-; nr_add_node+0x16b9/0x2f50 [netrom]
4,1384,2553527844,-; nr_rt_ioctl+0x13ee/0x2d20 [netrom]
4,1385,2553528464,-; nr_ioctl+0x12d/0x290 [netrom]
4,1386,2553529075,-; sock_do_ioctl+0x114/0x230
4,1387,2553529676,-; sock_ioctl+0x3a6/0x640
4,1388,2553530275,-; __x64_sys_ioctl+0x147/0x1e0
4,1389,2553530875,-; x64_sys_call+0x1060/0x2360
4,1390,2553531477,-; do_syscall_64+0x82/0x5d0
4,1391,2553532080,-; entry_SYSCALL_64_after_hwframe+0x76/0x7e
3,1392,2553532683,-;
3,1393,2553533276,-;Freed by task 4776 on cpu 1 at 2553.484760s:
4,1394,2553533882,-; kasan_save_stack+0x3a/0x70
4,1395,2553534486,-; kasan_save_track+0x18/0x70
4,1396,2553535094,-; kasan_save_free_info+0x3b/0x70
4,1397,2553535700,-; __kasan_slab_free+0x7a/0xb0
4,1398,2553536306,-; kfree+0x1ad/0x510
4,1399,2553536908,-; nr_rt_ioctl+0x648/0x2d20 [netrom]
4,1400,2553537513,-; nr_ioctl+0x12d/0x290 [netrom]
4,1401,2553538119,-; sock_do_ioctl+0x114/0x230
4,1402,2553538735,-; sock_ioctl+0x3a6/0x640
4,1403,2553539363,-; __x64_sys_ioctl+0x147/0x1e0
4,1404,2553539983,-; x64_sys_call+0x1060/0x2360
4,1405,2553540611,-; do_syscall_64+0x82/0x5d0
4,1406,2553541242,-; entry_SYSCALL_64_after_hwframe+0x76/0x7e
3,1407,2553541874,-;
3,1408,2553542499,-;The buggy address belongs to the object at ffff88811bc50e00\x0a which belongs to the cache kmalloc-rnd-09-64 of size 64
3,1409,2553543732,-;The buggy address is located 50 bytes inside of\x0a freed 64-byte region [ffff88811bc50e00, ffff88811bc50e40)
3,1410,2553544955,-;
3,1411,2553545570,-;The buggy address belongs to the physical page:
4,1412,2553546194,-;page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11bc50
4,1413,2553546833,-;ksm flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
4,1414,2553547477,-;page_type: f5(slab)
4,1415,2553548118,-;raw: 0017ffffc0000000 ffff888100051e00 ffffea00042c79c0 0000000000000003
4,1416,2553548774,-;raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000
4,1417,2553549428,-;page dumped because: kasan: bad access detected
3,1418,2553550087,-;
3,1419,2553550741,-;Memory state around the buggy address:
3,1420,2553551406,-; ffff88811bc50d00: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
3,1421,2553552083,-; ffff88811bc50d80: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
3,1422,2553552756,-;>ffff88811bc50e00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
3,1423,2553553428,-;                                     ^
3,1424,2553554104,-; ffff88811bc50e80: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
3,1425,2553554798,-; ffff88811bc50f00: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
3,1426,2553555505,-;==================================================================
4,1427,2553556264,-;Disabling lock debugging due to kernel taint
4,1428,2553557582,-;Oops: general protection fault, probably for non-canonical address 0xe00efc5800000255: 0000 [#1] SMP KASAN PTI
1,1429,2553558757,-;KASAN: maybe wild-memory-access in range [0x007802c0000012a8-0x007802c0000012af]
4,1430,2553559929,-;CPU: 1 UID: 0 PID: 4776 Comm: netromd Tainted: G    B               6.19.0-rc5-f6bvp+ #50 PREEMPT(voluntary) 
4,1431,2553561094,-;Tainted: [B]=BAD_PAGE
4,1432,2553561835,-;Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020
4,1433,2553562456,-;RIP: 0010:nr_rt_ioctl+0x6ef/0x2d20 [netrom]
4,1434,2553563054,-;Code: 85 c7 1c 00 00 4c 8b 73 08 4d 85 f6 74 58 48 89 d8 48 c1 e8 03 42 80 3c 38 00 0f 85 bc 1c 00 00 4c 89 f6 48 8b 03 48 c1 ee 03 <42> 80 3c 3e 00 0f 85 e0 1c 00 00 49 89 06 48 85 c0 74 1a 48 8d 78
4,1435,2553563699,-;RSP: 0018:ffff88810db57858 EFLAGS: 00010206
4,1436,2553564363,-;RAX: ffff8881a78b2a00 RBX: ffff88811bc50e00 RCX: 0000000000000000
4,1437,2553565026,-;RDX: 0000000000000000 RSI: 000f005800000255 RDI: 0000000000000000
4,1438,2553565687,-;RBP: ffff88810db57a20 R08: 0000000000000000 R09: 0000000000000000
4,1439,2553566351,-;R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881022ac980
4,1440,2553567011,-;R13: ffff8881022ac9a1 R14: 007802c0000012a8 R15: dffffc0000000000
4,1441,2553567675,-;FS:  000077cecd93a740(0000) GS:ffff888254ed6000(0000) knlGS:0000000000000000
4,1442,2553568348,-;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
4,1443,2553569022,-;CR2: 000077cecd7baff0 CR3: 0000000107942006 CR4: 00000000001726f0
4,1444,2553569698,-;Call Trace:
4,1445,2553570376,-; <TASK>
4,1446,2553571051,-; ? __pfx_nr_rt_ioctl+0x10/0x10 [netrom]
4,1447,2553571733,-; ? try_to_merge_with_ksm_page+0x170/0x2b0
4,1448,2553572432,-; ? apparmor_capable+0x159/0x470
4,1449,2553573129,-; ? security_capable+0x95/0x1c0
4,1450,2553573832,-; nr_ioctl+0x12d/0x290 [netrom]
4,1451,2553574529,-; ? alloc_empty_file+0xad/0x160
4,1452,2553575229,-; sock_do_ioctl+0x114/0x230
4,1453,2553575929,-; ? alloc_file_pseudo+0x163/0x230
4,1454,2553576620,-; ? __pfx_sock_do_ioctl+0x10/0x10
4,1455,2553577308,-; ? __pfx_alloc_file_pseudo+0x10/0x10
4,1456,2553577996,-; ? security_socket_post_create+0x78/0x200
4,1457,2553578680,-; ? __pfx_do_vfs_ioctl+0x10/0x10
4,1458,2553579366,-; ? sock_alloc_file+0xe2/0x220
4,1459,2553580045,-; sock_ioctl+0x3a6/0x640
4,1460,2553580722,-; ? __pfx_fput_close_sync+0x10/0x10
4,1461,2553581405,-; ? __pfx___sys_socket+0x10/0x10
4,1462,2553582087,-; ? __pfx_sock_ioctl+0x10/0x10
4,1463,2553582764,-; ? __kasan_check_read+0x11/0x20
4,1464,2553583445,-; ? hook_file_ioctl+0x10/0x20
4,1465,2553584130,-; __x64_sys_ioctl+0x147/0x1e0
4,1466,2553584810,-; x64_sys_call+0x1060/0x2360
4,1467,2553585993,-; do_syscall_64+0x82/0x5d0
4,1468,2553586668,-; ? __fput+0x554/0xaa0
4,1469,2553587347,-; ? fput_close_sync+0xe3/0x1b0
4,1470,2553588026,-; ? __pfx_fput_close_sync+0x10/0x10
4,1471,2553588717,-; ? __kasan_check_read+0x11/0x20
4,1472,2553589413,-; ? fpregs_assert_state_consistent+0x5c/0x100
4,1473,2553590099,-; ? do_syscall_64+0xbf/0x5d0
4,1474,2553590793,-; ? ksys_read+0x104/0x240
4,1475,2553591476,-; ? __pfx_ksys_read+0x10/0x10
4,1476,2553592155,-; ? __kasan_check_read+0x11/0x20
4,1477,2553592832,-; ? fpregs_assert_state_consistent+0x5c/0x100
4,1478,2553593493,-; ? do_syscall_64+0xbf/0x5d0
4,1479,2553594151,-; ? exc_page_fault+0x95/0x100
4,1480,2553594802,-; entry_SYSCALL_64_after_hwframe+0x76/0x7e
4,1481,2553595451,-;RIP: 0033:0x77cecd73287d
4,1482,2553596093,-;Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
4,1483,2553596793,-;RSP: 002b:00007fff83cb9d10 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
4,1484,2553597503,-;RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 000077cecd73287d
4,1485,2553598212,-;RDX: 00007fff83cb9dcc RSI: 00000000000089e2 RDI: 0000000000000005
4,1486,2553598925,-;RBP: 00007fff83cb9d60 R08: 0000000000000000 R09: 0000000000000000
4,1487,2553599621,-;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000078
4,1488,2553600325,-;R13: 0000601de2d57a60 R14: 00007fff83cb9ef0 R15: 0000601dc3550159
4,1489,2553601035,-; </TASK>
4,1490,2553601726,-,ncfrag=0/1007;Modules linked in: netrom mkiss rose ax25 netconsole snd_seq_dummy snd_hrtimer cmac nls_utf8 cifs nls_ucs2_utils libarc4 netfs cifs_md4 x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_alc269 snd_hda_scodec_component snd_hda_codec_realtek_lib kvm_intel snd_hda_codec_generic snd_hda_codec_intelhdmi snd_hda_codec_hdmi spi_nor mtd snd_hda_intel kvm snd_intel_dspcfg irqbypass snd_hda_codec ghash_clmulni_intel aesni_intel snd_hwdep rapl intel_cstate qrtr snd_hda_core spi_intel_platform at24 spi_intel mei_hdcp mei_pxp intel_rapl_msr i915 snd_pcm processor_thermal_device_pci_legacy intel_soc_dts_iosf processor_thermal_device snd_seq processor_thermal_wt_hint platform_temperature_control i2c_i801 processor_thermal_soc_slider intel_pch_thermal i2c_smbus snd_seq_device i2c_algo_bit platform_profile snd_timer processor_thermal_rfim drm_buddy processor_thermal_rapl lpc_ich intel_rapl_common mei_me processor_thermal_wt_req snd processor_thermal_power_fl4,1490,2553601726,-,ncfrag=966/1007;oor ttm mei drm_display_helper soundcore
4,1491,2553601869,c; processor_thermal_mbox int340x_thermal_zone input_leds nls_iso8859_1 intel_pmc_core video wmi pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec acpi_pad mac_hid binfmt_misc sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs autofs4 hid_generic usbhid hid r8169 ahci realtek libahci uas usb_storage [last unloaded: mkiss]
4,1492,2553607611,-;---[ end trace 0000000000000000 ]---
3,1493,2553649506,-;pstore: backend (efi_pstore) writing error (-5)
4,1494,2553650533,-;RIP: 0010:nr_rt_ioctl+0x6ef/0x2d20 [netrom]
4,1495,2553651547,-;Code: 85 c7 1c 00 00 4c 8b 73 08 4d 85 f6 74 58 48 89 d8 48 c1 e8 03 42 80 3c 38 00 0f 85 bc 1c 00 00 4c 89 f6 48 8b 03 48 c1 ee 03 <42> 80 3c 3e 00 0f 85 e0 1c 00 00 49 89 06 48 85 c0 74 1a 48 8d 78
4,1496,2553652649,-;RSP: 0018:ffff88810db57858 EFLAGS: 00010206
4,1497,2553653658,-;RAX: ffff8881a78b2a00 RBX: ffff88811bc50e00 RCX: 0000000000000000
4,1498,2553654710,-;RDX: 0000000000000000 RSI: 000f005800000255 RDI: 0000000000000000
4,1499,2553655722,-;RBP: ffff88810db57a20 R08: 0000000000000000 R09: 0000000000000000
4,1500,2553656871,-;R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881022ac980
4,1501,2553657916,-;R13: ffff8881022ac9a1 R14: 007802c0000012a8 R15: dffffc0000000000
4,1502,2553659046,-;FS:  000077cecd93a740(0000) GS:ffff888254ed6000(0000) knlGS:0000000000000000
4,1503,2553660069,-;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
4,1504,2553661125,-;CR2: 000077cecd7baff0 CR3: 0000000107942006 CR4: 00000000001726f0
0,1505,2553662153,-;Kernel panic - not syncing: Fatal exception in interrupt
0,1506,2553663142,-;Kernel Offset: 0x33200000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
0,1507,2553705726,-;Rebooting in 30 seconds..


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Testing for netrom: fix memory leak in nr_add_node
  2026-01-20 21:02         ` F6BVP
@ 2026-01-22 17:27           ` Prithvi
  0 siblings, 0 replies; 15+ messages in thread
From: Prithvi @ 2026-01-22 17:27 UTC (permalink / raw)
  To: F6BVP
  Cc: dranch, davem, edumazet, horms, kuba, linux-hams, linux-kernel,
	netdev, pabeni, syzbot+3f2d46b6e62b8dd546d3, syzkaller-bugs

On Tue, Jan 20, 2026 at 10:02:49PM +0100, F6BVP wrote:
> 
> 
> Le 20/01/2026 à 17:00, Prithvi a écrit :
> > Hello Bernard and David,
> > 
> > Thank you very much for your feedback. I sincerely apologize for the
> > instability caused due to this patch. I take this instability very
> > seriously.
> > 
> > Unfortunately I am on a low-end backup system right now which does not have
> > resources to build or boot custom kernels effectively, locally. That's why,
> > it has been difficult for me to test the patch locally due to which I have
> > been relying on syzbot for testing. I am grateful for your feedback by
> > testing that patch on your setup.
> > 
> > I will work on investigating further why the kernel isn't stable with this
> > patch and try to create a better fix for this bug.
> > 
> > Thanks a lot Bernard for testing this patch. In case you get any crash
> > dump or similar information, it would be very helpful to understand the issue
> > and fix it.
> > 
> > Thank you very much and best regards,
> > Prithvi
> > 
> Hi Prithvi,
> 
> Your effort in improving netrom protocole AX25 is appreciated.
> I reactivated netconsole between my two ROSE FPAC nodes machines in order to
> catch kernel panic triggered by adding your line of patch.
> 
> Regards,
> 
> Bernard, f6bvp

> 
> 
> 6,1306,1249564798,-;NET: Registered PF_AX25 protocol family
> 6,1307,1249581517,-;mkiss: AX.25 Multikiss, Hans Albas PE1AYX
> 6,1308,1249627212,-;NET: Registered PF_ROSE protocol family
> 6,1309,1252718950,-;mkiss: AX.25 Multikiss, Hans Albas PE1AYX
> 6,1310,1252721666,-;mkiss: ax0: crc mode is auto.
> 6,1311,1254808312,-;NET: Registered PF_NETROM protocol family
> 6,1312,1266780331,-;mkiss: ax0: Trying crc-smack
> 6,1313,1266782411,-;mkiss: ax0: Trying crc-flexnet
> 3,1314,2553484762,-;==================================================================
> 3,1315,2553485598,-;BUG: KASAN: slab-use-after-free in nr_rt_ioctl+0x2073/0x2d20 [netrom]
> 3,1316,2553486313,-;Read of size 2 at addr ffff88811bc50e32 by task netromd/4776
> 3,1317,2553486860,-;
> 3,1318,2553487398,-;CPU: 1 UID: 0 PID: 4776 Comm: netromd Not tainted 6.19.0-rc5-f6bvp+ #50 PREEMPT(voluntary) 
> 3,1319,2553487403,-;Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020
> 3,1320,2553487406,-;Call Trace:
> 3,1321,2553487407,-; <TASK>
> 3,1322,2553487409,-; dump_stack_lvl+0x5f/0x90
> 3,1323,2553487415,-; print_report+0x171/0x4f5
> 3,1324,2553487420,-; ? __pfx__raw_spin_lock_irqsave+0x10/0x10
> 3,1325,2553487425,-; ? sched_clock_noinstr+0x9/0x10
> 3,1326,2553487430,-; ? kasan_complete_mode_report_info+0x88/0x230
> 3,1327,2553487437,-; kasan_report+0xf2/0x130
> 3,1328,2553487440,-; ? nr_rt_ioctl+0x2073/0x2d20 [netrom]
> 3,1329,2553487447,-; ? nr_rt_ioctl+0x2073/0x2d20 [netrom]
> 3,1330,2553487453,-; __asan_report_load2_noabort+0x14/0x30
> 3,1331,2553487457,-; nr_rt_ioctl+0x2073/0x2d20 [netrom]
> 3,1332,2553487465,-; ? __pfx_nr_rt_ioctl+0x10/0x10 [netrom]
> 3,1333,2553487471,-; ? try_to_merge_with_ksm_page+0x170/0x2b0
> 3,1334,2553487476,-; ? apparmor_capable+0x159/0x470
> 3,1335,2553487482,-; ? security_capable+0x95/0x1c0
> 3,1336,2553487488,-; nr_ioctl+0x12d/0x290 [netrom]
> 3,1337,2553487493,-; ? alloc_empty_file+0xad/0x160
> 3,1338,2553487498,-; sock_do_ioctl+0x114/0x230
> 3,1339,2553487504,-; ? alloc_file_pseudo+0x163/0x230
> 3,1340,2553487507,-; ? __pfx_sock_do_ioctl+0x10/0x10
> 3,1341,2553487511,-; ? __pfx_alloc_file_pseudo+0x10/0x10
> 3,1342,2553487514,-; ? security_socket_post_create+0x78/0x200
> 3,1343,2553487519,-; ? __pfx_do_vfs_ioctl+0x10/0x10
> 3,1344,2553487525,-; ? sock_alloc_file+0xe2/0x220
> 3,1345,2553487529,-; sock_ioctl+0x3a6/0x640
> 3,1346,2553487532,-; ? __pfx_fput_close_sync+0x10/0x10
> 3,1347,2553487535,-; ? __pfx___sys_socket+0x10/0x10
> 3,1348,2553487538,-; ? __pfx_sock_ioctl+0x10/0x10
> 3,1349,2553487541,-; ? __kasan_check_read+0x11/0x20
> 3,1350,2553487545,-; ? hook_file_ioctl+0x10/0x20
> 3,1351,2553487550,-; __x64_sys_ioctl+0x147/0x1e0
> 3,1352,2553487554,-; x64_sys_call+0x1060/0x2360
> 3,1353,2553487558,-; do_syscall_64+0x82/0x5d0
> 3,1354,2553487561,-; ? __fput+0x554/0xaa0
> 3,1355,2553487565,-; ? fput_close_sync+0xe3/0x1b0
> 3,1356,2553487569,-; ? __pfx_fput_close_sync+0x10/0x10
> 3,1357,2553487573,-; ? __kasan_check_read+0x11/0x20
> 3,1358,2553487576,-; ? fpregs_assert_state_consistent+0x5c/0x100
> 3,1359,2553487581,-; ? do_syscall_64+0xbf/0x5d0
> 3,1360,2553487584,-; ? ksys_read+0x104/0x240
> 3,1361,2553487587,-; ? __pfx_ksys_read+0x10/0x10
> 3,1362,2553487591,-; ? __kasan_check_read+0x11/0x20
> 3,1363,2553487595,-; ? fpregs_assert_state_consistent+0x5c/0x100
> 3,1364,2553487598,-; ? do_syscall_64+0xbf/0x5d0
> 3,1365,2553487601,-; ? exc_page_fault+0x95/0x100
> 3,1366,2553487605,-; entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 3,1367,2553487608,-;RIP: 0033:0x77cecd73287d
> 3,1368,2553487612,-;Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
> 3,1369,2553487615,-;RSP: 002b:00007fff83cb9d10 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> 3,1370,2553487620,-;RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 000077cecd73287d
> 3,1371,2553487623,-;RDX: 00007fff83cb9dcc RSI: 00000000000089e2 RDI: 0000000000000005
> 3,1372,2553487625,-;RBP: 00007fff83cb9d60 R08: 0000000000000000 R09: 0000000000000000
> 3,1373,2553487627,-;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000078
> 3,1374,2553487630,-;R13: 0000601de2d57a60 R14: 00007fff83cb9ef0 R15: 0000601dc3550159
> 3,1375,2553487634,-; </TASK>
> 3,1376,2553487635,-;
> 3,1377,2553522861,-;Allocated by task 4511 on cpu 3 at 1255.067864s:
> 4,1378,2553523540,-; kasan_save_stack+0x3a/0x70
> 4,1379,2553524231,-; kasan_save_track+0x18/0x70
> 4,1380,2553524918,-; kasan_save_alloc_info+0x39/0x60
> 4,1381,2553525593,-; __kasan_kmalloc+0xa9/0xd0
> 4,1382,2553526563,-; __kmalloc_cache_noprof+0x20b/0x5b0
> 4,1383,2553527209,-; nr_add_node+0x16b9/0x2f50 [netrom]
> 4,1384,2553527844,-; nr_rt_ioctl+0x13ee/0x2d20 [netrom]
> 4,1385,2553528464,-; nr_ioctl+0x12d/0x290 [netrom]
> 4,1386,2553529075,-; sock_do_ioctl+0x114/0x230
> 4,1387,2553529676,-; sock_ioctl+0x3a6/0x640
> 4,1388,2553530275,-; __x64_sys_ioctl+0x147/0x1e0
> 4,1389,2553530875,-; x64_sys_call+0x1060/0x2360
> 4,1390,2553531477,-; do_syscall_64+0x82/0x5d0
> 4,1391,2553532080,-; entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 3,1392,2553532683,-;
> 3,1393,2553533276,-;Freed by task 4776 on cpu 1 at 2553.484760s:
> 4,1394,2553533882,-; kasan_save_stack+0x3a/0x70
> 4,1395,2553534486,-; kasan_save_track+0x18/0x70
> 4,1396,2553535094,-; kasan_save_free_info+0x3b/0x70
> 4,1397,2553535700,-; __kasan_slab_free+0x7a/0xb0
> 4,1398,2553536306,-; kfree+0x1ad/0x510
> 4,1399,2553536908,-; nr_rt_ioctl+0x648/0x2d20 [netrom]
> 4,1400,2553537513,-; nr_ioctl+0x12d/0x290 [netrom]
> 4,1401,2553538119,-; sock_do_ioctl+0x114/0x230
> 4,1402,2553538735,-; sock_ioctl+0x3a6/0x640
> 4,1403,2553539363,-; __x64_sys_ioctl+0x147/0x1e0
> 4,1404,2553539983,-; x64_sys_call+0x1060/0x2360
> 4,1405,2553540611,-; do_syscall_64+0x82/0x5d0
> 4,1406,2553541242,-; entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 3,1407,2553541874,-;
> 3,1408,2553542499,-;The buggy address belongs to the object at ffff88811bc50e00\x0a which belongs to the cache kmalloc-rnd-09-64 of size 64
> 3,1409,2553543732,-;The buggy address is located 50 bytes inside of\x0a freed 64-byte region [ffff88811bc50e00, ffff88811bc50e40)
> 3,1410,2553544955,-;
> 3,1411,2553545570,-;The buggy address belongs to the physical page:
> 4,1412,2553546194,-;page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11bc50
> 4,1413,2553546833,-;ksm flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
> 4,1414,2553547477,-;page_type: f5(slab)
> 4,1415,2553548118,-;raw: 0017ffffc0000000 ffff888100051e00 ffffea00042c79c0 0000000000000003
> 4,1416,2553548774,-;raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000
> 4,1417,2553549428,-;page dumped because: kasan: bad access detected
> 3,1418,2553550087,-;
> 3,1419,2553550741,-;Memory state around the buggy address:
> 3,1420,2553551406,-; ffff88811bc50d00: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
> 3,1421,2553552083,-; ffff88811bc50d80: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
> 3,1422,2553552756,-;>ffff88811bc50e00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> 3,1423,2553553428,-;                                     ^
> 3,1424,2553554104,-; ffff88811bc50e80: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
> 3,1425,2553554798,-; ffff88811bc50f00: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
> 3,1426,2553555505,-;==================================================================
> 4,1427,2553556264,-;Disabling lock debugging due to kernel taint
> 4,1428,2553557582,-;Oops: general protection fault, probably for non-canonical address 0xe00efc5800000255: 0000 [#1] SMP KASAN PTI
> 1,1429,2553558757,-;KASAN: maybe wild-memory-access in range [0x007802c0000012a8-0x007802c0000012af]
> 4,1430,2553559929,-;CPU: 1 UID: 0 PID: 4776 Comm: netromd Tainted: G    B               6.19.0-rc5-f6bvp+ #50 PREEMPT(voluntary) 
> 4,1431,2553561094,-;Tainted: [B]=BAD_PAGE
> 4,1432,2553561835,-;Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020
> 4,1433,2553562456,-;RIP: 0010:nr_rt_ioctl+0x6ef/0x2d20 [netrom]
> 4,1434,2553563054,-;Code: 85 c7 1c 00 00 4c 8b 73 08 4d 85 f6 74 58 48 89 d8 48 c1 e8 03 42 80 3c 38 00 0f 85 bc 1c 00 00 4c 89 f6 48 8b 03 48 c1 ee 03 <42> 80 3c 3e 00 0f 85 e0 1c 00 00 49 89 06 48 85 c0 74 1a 48 8d 78
> 4,1435,2553563699,-;RSP: 0018:ffff88810db57858 EFLAGS: 00010206
> 4,1436,2553564363,-;RAX: ffff8881a78b2a00 RBX: ffff88811bc50e00 RCX: 0000000000000000
> 4,1437,2553565026,-;RDX: 0000000000000000 RSI: 000f005800000255 RDI: 0000000000000000
> 4,1438,2553565687,-;RBP: ffff88810db57a20 R08: 0000000000000000 R09: 0000000000000000
> 4,1439,2553566351,-;R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881022ac980
> 4,1440,2553567011,-;R13: ffff8881022ac9a1 R14: 007802c0000012a8 R15: dffffc0000000000
> 4,1441,2553567675,-;FS:  000077cecd93a740(0000) GS:ffff888254ed6000(0000) knlGS:0000000000000000
> 4,1442,2553568348,-;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> 4,1443,2553569022,-;CR2: 000077cecd7baff0 CR3: 0000000107942006 CR4: 00000000001726f0
> 4,1444,2553569698,-;Call Trace:
> 4,1445,2553570376,-; <TASK>
> 4,1446,2553571051,-; ? __pfx_nr_rt_ioctl+0x10/0x10 [netrom]
> 4,1447,2553571733,-; ? try_to_merge_with_ksm_page+0x170/0x2b0
> 4,1448,2553572432,-; ? apparmor_capable+0x159/0x470
> 4,1449,2553573129,-; ? security_capable+0x95/0x1c0
> 4,1450,2553573832,-; nr_ioctl+0x12d/0x290 [netrom]
> 4,1451,2553574529,-; ? alloc_empty_file+0xad/0x160
> 4,1452,2553575229,-; sock_do_ioctl+0x114/0x230
> 4,1453,2553575929,-; ? alloc_file_pseudo+0x163/0x230
> 4,1454,2553576620,-; ? __pfx_sock_do_ioctl+0x10/0x10
> 4,1455,2553577308,-; ? __pfx_alloc_file_pseudo+0x10/0x10
> 4,1456,2553577996,-; ? security_socket_post_create+0x78/0x200
> 4,1457,2553578680,-; ? __pfx_do_vfs_ioctl+0x10/0x10
> 4,1458,2553579366,-; ? sock_alloc_file+0xe2/0x220
> 4,1459,2553580045,-; sock_ioctl+0x3a6/0x640
> 4,1460,2553580722,-; ? __pfx_fput_close_sync+0x10/0x10
> 4,1461,2553581405,-; ? __pfx___sys_socket+0x10/0x10
> 4,1462,2553582087,-; ? __pfx_sock_ioctl+0x10/0x10
> 4,1463,2553582764,-; ? __kasan_check_read+0x11/0x20
> 4,1464,2553583445,-; ? hook_file_ioctl+0x10/0x20
> 4,1465,2553584130,-; __x64_sys_ioctl+0x147/0x1e0
> 4,1466,2553584810,-; x64_sys_call+0x1060/0x2360
> 4,1467,2553585993,-; do_syscall_64+0x82/0x5d0
> 4,1468,2553586668,-; ? __fput+0x554/0xaa0
> 4,1469,2553587347,-; ? fput_close_sync+0xe3/0x1b0
> 4,1470,2553588026,-; ? __pfx_fput_close_sync+0x10/0x10
> 4,1471,2553588717,-; ? __kasan_check_read+0x11/0x20
> 4,1472,2553589413,-; ? fpregs_assert_state_consistent+0x5c/0x100
> 4,1473,2553590099,-; ? do_syscall_64+0xbf/0x5d0
> 4,1474,2553590793,-; ? ksys_read+0x104/0x240
> 4,1475,2553591476,-; ? __pfx_ksys_read+0x10/0x10
> 4,1476,2553592155,-; ? __kasan_check_read+0x11/0x20
> 4,1477,2553592832,-; ? fpregs_assert_state_consistent+0x5c/0x100
> 4,1478,2553593493,-; ? do_syscall_64+0xbf/0x5d0
> 4,1479,2553594151,-; ? exc_page_fault+0x95/0x100
> 4,1480,2553594802,-; entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 4,1481,2553595451,-;RIP: 0033:0x77cecd73287d
> 4,1482,2553596093,-;Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
> 4,1483,2553596793,-;RSP: 002b:00007fff83cb9d10 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> 4,1484,2553597503,-;RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 000077cecd73287d
> 4,1485,2553598212,-;RDX: 00007fff83cb9dcc RSI: 00000000000089e2 RDI: 0000000000000005
> 4,1486,2553598925,-;RBP: 00007fff83cb9d60 R08: 0000000000000000 R09: 0000000000000000
> 4,1487,2553599621,-;R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000078
> 4,1488,2553600325,-;R13: 0000601de2d57a60 R14: 00007fff83cb9ef0 R15: 0000601dc3550159
> 4,1489,2553601035,-; </TASK>
> 4,1490,2553601726,-,ncfrag=0/1007;Modules linked in: netrom mkiss rose ax25 netconsole snd_seq_dummy snd_hrtimer cmac nls_utf8 cifs nls_ucs2_utils libarc4 netfs cifs_md4 x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_alc269 snd_hda_scodec_component snd_hda_codec_realtek_lib kvm_intel snd_hda_codec_generic snd_hda_codec_intelhdmi snd_hda_codec_hdmi spi_nor mtd snd_hda_intel kvm snd_intel_dspcfg irqbypass snd_hda_codec ghash_clmulni_intel aesni_intel snd_hwdep rapl intel_cstate qrtr snd_hda_core spi_intel_platform at24 spi_intel mei_hdcp mei_pxp intel_rapl_msr i915 snd_pcm processor_thermal_device_pci_legacy intel_soc_dts_iosf processor_thermal_device snd_seq processor_thermal_wt_hint platform_temperature_control i2c_i801 processor_thermal_soc_slider intel_pch_thermal i2c_smbus snd_seq_device i2c_algo_bit platform_profile snd_timer processor_thermal_rfim drm_buddy processor_thermal_rapl lpc_ich intel_rapl_common mei_me processor_thermal_wt_req snd processor_thermal_power_fl4,1490,2553601726,-,ncfrag=966/1007;oor ttm mei drm_display_helper soundcore
> 4,1491,2553601869,c; processor_thermal_mbox int340x_thermal_zone input_leds nls_iso8859_1 intel_pmc_core video wmi pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec acpi_pad mac_hid binfmt_misc sch_fq_codel msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs autofs4 hid_generic usbhid hid r8169 ahci realtek libahci uas usb_storage [last unloaded: mkiss]
> 4,1492,2553607611,-;---[ end trace 0000000000000000 ]---
> 3,1493,2553649506,-;pstore: backend (efi_pstore) writing error (-5)
> 4,1494,2553650533,-;RIP: 0010:nr_rt_ioctl+0x6ef/0x2d20 [netrom]
> 4,1495,2553651547,-;Code: 85 c7 1c 00 00 4c 8b 73 08 4d 85 f6 74 58 48 89 d8 48 c1 e8 03 42 80 3c 38 00 0f 85 bc 1c 00 00 4c 89 f6 48 8b 03 48 c1 ee 03 <42> 80 3c 3e 00 0f 85 e0 1c 00 00 49 89 06 48 85 c0 74 1a 48 8d 78
> 4,1496,2553652649,-;RSP: 0018:ffff88810db57858 EFLAGS: 00010206
> 4,1497,2553653658,-;RAX: ffff8881a78b2a00 RBX: ffff88811bc50e00 RCX: 0000000000000000
> 4,1498,2553654710,-;RDX: 0000000000000000 RSI: 000f005800000255 RDI: 0000000000000000
> 4,1499,2553655722,-;RBP: ffff88810db57a20 R08: 0000000000000000 R09: 0000000000000000
> 4,1500,2553656871,-;R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881022ac980
> 4,1501,2553657916,-;R13: ffff8881022ac9a1 R14: 007802c0000012a8 R15: dffffc0000000000
> 4,1502,2553659046,-;FS:  000077cecd93a740(0000) GS:ffff888254ed6000(0000) knlGS:0000000000000000
> 4,1503,2553660069,-;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> 4,1504,2553661125,-;CR2: 000077cecd7baff0 CR3: 0000000107942006 CR4: 00000000001726f0
> 0,1505,2553662153,-;Kernel panic - not syncing: Fatal exception in interrupt
> 0,1506,2553663142,-;Kernel Offset: 0x33200000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> 0,1507,2553705726,-;Rebooting in 30 seconds..
> 

Hello Bernard,

Thanks for sharing the kernel panic log. I will try my best to resolve 
the issue.

Best Regards,
Prithvi

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2026-01-22 17:27 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-15 20:04 [syzbot] [hams?] memory leak in nr_add_node syzbot
2026-01-16  2:19 ` Forwarded: [PATCH] netrom: fix memory leak in nr_add_node() syzbot
2026-01-16  3:40 ` syzbot
2026-01-16  7:42 ` syzbot
2026-01-16  8:28 ` syzbot
2026-01-16  8:59 ` syzbot
2026-01-16  9:39 ` syzbot
2026-01-16 12:51 ` syzbot
2026-01-17 14:26 ` Testing for netrom: fix memory leak in nr_add_node Prithvi Tambewagh
2026-01-17 17:00   ` [syzbot] [hams?] " syzbot
2026-01-19 21:06   ` Testing for netrom: fix " F6BVP
2026-01-20  3:37     ` David Ranch
2026-01-20 16:00       ` Prithvi
2026-01-20 21:02         ` F6BVP
2026-01-22 17:27           ` Prithvi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox