[syzbot] [net?] UBSAN: array-index-out-of-bounds in mr_table_dump

[syzbot] [net?] UBSAN: array-index-out-of-bounds in mr_table_dump

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    573067a5a685 Merge branch 'for-next/core' into for-kernelci
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=12d70dc4580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=cd7202b56d469648
dashboard link: https://syzkaller.appspot.com/bug?extid=5cfae50c0e5f2c500013
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
userspace arch: arm64
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13770ef8580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1647e4b0580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/9d3b5c855aa0/disk-573067a5.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0c06fc1ead83/vmlinux-573067a5.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3390e59b9e4b/Image-573067a5.gz.xz

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

syz_tun: entered allmulticast mode
------------[ cut here ]------------
UBSAN: array-index-out-of-bounds in net/ipv4/ipmr_base.c:289:10
index -772737152 is out of range for type 'const struct vif_device[32]'
CPU: 1 UID: 0 PID: 6411 Comm: syz-executor937 Not tainted 6.13.0-rc3-syzkaller-g573067a5a685 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call trace:
 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120
 dump_stack+0x1c/0x28 lib/dump_stack.c:129
 ubsan_epilogue lib/ubsan.c:231 [inline]
 __ubsan_handle_out_of_bounds+0xf8/0x148 lib/ubsan.c:429
 mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline]
 mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334
 mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382
 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648
 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4326
 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6790
 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317
 __netlink_dump_start+0x4d8/0x720 net/netlink/af_netlink.c:2432
 netlink_dump_start include/linux/netlink.h:340 [inline]
 rtnetlink_dump_start net/core/rtnetlink.c:6819 [inline]
 rtnetlink_rcv_msg+0x8fc/0xa9c net/core/rtnetlink.c:6886
 netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2542
 rtnetlink_rcv+0x28/0x38 net/core/rtnetlink.c:6948
 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]
 netlink_unicast+0x668/0x8a4 net/netlink/af_netlink.c:1347
 netlink_sendmsg+0x7a4/0xa8c net/netlink/af_netlink.c:1891
 sock_sendmsg_nosec net/socket.c:711 [inline]
 __sock_sendmsg net/socket.c:726 [inline]
 sock_write_iter+0x2d8/0x448 net/socket.c:1147
 new_sync_write fs/read_write.c:586 [inline]
 vfs_write+0x920/0xcf4 fs/read_write.c:679
 ksys_write+0x15c/0x26c fs/read_write.c:731
 __do_sys_write fs/read_write.c:742 [inline]
 __se_sys_write fs/read_write.c:739 [inline]
 __arm64_sys_write+0x7c/0x90 fs/read_write.c:739
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744
 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
---[ end trace ]---
Unable to handle kernel paging request at virtual address ffff5ffd9650c113
KASAN: maybe wild-memory-access in range [0xfffeffecb2860898-0xfffeffecb286089f]
Mem abort info:
  ESR = 0x0000000096000004
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x04: level 0 translation fault
Data abort info:
  ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
  CM = 0, WnR = 0, TnD = 0, TagAccess = 0
  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000001a5699000
[ffff5ffd9650c113] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 UID: 0 PID: 6411 Comm: syz-executor937 Not tainted 6.13.0-rc3-syzkaller-g573067a5a685 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline]
pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334
lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline]
lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334
sp : ffff8000a50c6e10
x29: ffff8000a50c6ed0 x28: fffeffecb2860898 x27: ffffffffd1f0f780
x26: ffffffffd1f0f780 x25: 0000000000000000 x24: fffeffecb2860898
x23: dfff800000000000 x22: 00000000d1f0f780 x21: ffff00009a3377c8
x20: dfff800000000000 x19: ffff0000c8428078 x18: 0000000000000008
x17: 0000000000000000 x16: ffff80008b5fe85c x15: ffff7000125d8a48
x14: 1ffff000125d8a48 x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff7000125d8a48 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 1fffdffd9650c113 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff8000a50c64f8 x4 : ffff80008fa8f840 x3 : ffff8000802f4dc8
x2 : 0000000000000001 x1 : 0000000000000001 x0 : 00000000ffffffff
Call trace:
 mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P)
 mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P)
 mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382
 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648
 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4326
 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6790
 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317
 __netlink_dump_start+0x4d8/0x720 net/netlink/af_netlink.c:2432
 netlink_dump_start include/linux/netlink.h:340 [inline]
 rtnetlink_dump_start net/core/rtnetlink.c:6819 [inline]
 rtnetlink_rcv_msg+0x8fc/0xa9c net/core/rtnetlink.c:6886
 netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2542
 rtnetlink_rcv+0x28/0x38 net/core/rtnetlink.c:6948
 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]
 netlink_unicast+0x668/0x8a4 net/netlink/af_netlink.c:1347
 netlink_sendmsg+0x7a4/0xa8c net/netlink/af_netlink.c:1891
 sock_sendmsg_nosec net/socket.c:711 [inline]
 __sock_sendmsg net/socket.c:726 [inline]
 sock_write_iter+0x2d8/0x448 net/socket.c:1147
 new_sync_write fs/read_write.c:586 [inline]
 vfs_write+0x920/0xcf4 fs/read_write.c:679
 ksys_write+0x15c/0x26c fs/read_write.c:731
 __do_sys_write fs/read_write.c:742 [inline]
 __se_sys_write fs/read_write.c:739 [inline]
 __arm64_sys_write+0x7c/0x90 fs/read_write.c:739
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744
 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Code: 97759d2c d343ff08 d2d00017 f2fbfff7 (38746908) 
---[ end trace 0000000000000000 ]---
----------------
Code disassembly (best guess):
   0:	97759d2c 	bl	0xfffffffffdd674b0
   4:	d343ff08 	lsr	x8, x24, #3
   8:	d2d00017 	mov	x23, #0x800000000000        	// #140737488355328
   c:	f2fbfff7 	movk	x23, #0xdfff, lsl #48
* 10:	38746908 	ldrb	w8, [x8, x20] <-- trapping instruction


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

[PATCH] net: ipmr: Fix out-of-bounds access in mr_mfc_uses_dev()

[Abdullah]

Signed-off-by: Abdullah <asharji1828@gmail.com>
---
 net/ipv4/ipmr_base.c | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ipmr_base.c b/net/ipv4/ipmr_base.c
index 03b6eee407a2..7c38d0cf41fc 100644
--- a/net/ipv4/ipmr_base.c
+++ b/net/ipv4/ipmr_base.c
@@ -280,9 +280,31 @@ static bool mr_mfc_uses_dev(const struct mr_table *mrt,
 			    const struct mr_mfc *c,
 			    const struct net_device *dev)
 {
+	/**
+	* Helper function that checks if *dev is part of the OIL (Outgoing Interfaces List).
+	* @mrt: Is the multi-routing table.
+	* @c: Is the Multicast Forwarding Cache.
+	* @dev: The net device being checked.
+	*
+	* vif_dev: Pointer to the net device's struct.
+	* vif: Pointer to the actual device.
+	*
+	* OIL is a subset of mrt->vif_table[].
+	* minvif: Start index of OIL in vif_table[].
+	* maxvif: End index of OIL in vif_table[].
+	*
+	* Returns:
+	* - true if `dev` is part of the OIL.
+	* - false otherwise.
+	*/
+
 	int ct;
+	
+	int minvif = c->mfc_un.res.minvif, maxvif = c->mfc_un.res.maxvif;
+	if (minvif < 0 || maxvif > 32)
+		return false;
 
-	for (ct = c->mfc_un.res.minvif; ct < c->mfc_un.res.maxvif; ct++) {
+	for (ct = minvif; ct < maxvif; ct++) {
 		const struct net_device *vif_dev;
 		const struct vif_device *vif;
 
@@ -309,7 +331,8 @@ int mr_table_dump(struct mr_table *mrt, struct sk_buff *skb,
 
 	if (filter->filter_set)
 		flags |= NLM_F_DUMP_FILTERED;
-
+	
+	rcu_read_lock();
 	list_for_each_entry_rcu(mfc, &mrt->mfc_cache_list, list,
 				lockdep_rtnl_is_held()) {
 		if (e < s_e)
@@ -325,7 +348,8 @@ int mr_table_dump(struct mr_table *mrt, struct sk_buff *skb,
 next_entry:
 		e++;
 	}
-
+	rcu_read_unlock();
+	
 	spin_lock_bh(lock);
 	list_for_each_entry(mfc, &mrt->mfc_unres_queue, list) {
 		if (e < s_e)
-- 
2.43.0

[PATCH v2] net: ipmr: Fix out-of-bounds access in mr_mfc_uses_dev()

[Abdullah]

The issue was reported by Syzbot as an out-of-bounds read:
UBSAN: array-index-out-of-bounds in net/ipv4/ipmr_base.c:289:10
Index -772737152 is out of range for type 'const struct vif_device[32]'

The problem occurs when the minvif/maxvif values in the mr_mfc struct
become invalid (possibly due to memory corruption or uninitialized values).
This patch fixes the issue by ensuring proper boundary checks and rcu_read
locking before accessing vif_table[] in mr_mfc_uses_dev().

Fixes: <COMMIT_HASH>
Reported-by: syzbot+5cfae50c0e5f2c500013@syzkaller.appspotmail.com
Signed-off-by: Abdullah <asharji1828@gmail.com>
---
 net/ipv4/ipmr_base.c | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ipmr_base.c b/net/ipv4/ipmr_base.c
index 03b6eee407a2..7c38d0cf41fc 100644
--- a/net/ipv4/ipmr_base.c
+++ b/net/ipv4/ipmr_base.c
@@ -280,9 +280,31 @@ static bool mr_mfc_uses_dev(const struct mr_table *mrt,
 			    const struct mr_mfc *c,
 			    const struct net_device *dev)
 {
+	/**
+	* Helper function that checks if *dev is part of the OIL (Outgoing Interfaces List).
+	* @mrt: Is the multi-routing table.
+	* @c: Is the Multicast Forwarding Cache.
+	* @dev: The net device being checked.
+	*
+	* vif_dev: Pointer to the net device's struct.
+	* vif: Pointer to the actual device.
+	*
+	* OIL is a subset of mrt->vif_table[].
+	* minvif: Start index of OIL in vif_table[].
+	* maxvif: End index of OIL in vif_table[].
+	*
+	* Returns:
+	* - true if `dev` is part of the OIL.
+	* - false otherwise.
+	*/
+
 	int ct;
+	
+	int minvif = c->mfc_un.res.minvif, maxvif = c->mfc_un.res.maxvif;
+	if (minvif < 0 || maxvif > 32)
+		return false;
 
-	for (ct = c->mfc_un.res.minvif; ct < c->mfc_un.res.maxvif; ct++) {
+	for (ct = minvif; ct < maxvif; ct++) {
 		const struct net_device *vif_dev;
 		const struct vif_device *vif;
 
@@ -309,7 +331,8 @@ int mr_table_dump(struct mr_table *mrt, struct sk_buff *skb,
 
 	if (filter->filter_set)
 		flags |= NLM_F_DUMP_FILTERED;
-
+	
+	rcu_read_lock();
 	list_for_each_entry_rcu(mfc, &mrt->mfc_cache_list, list,
 				lockdep_rtnl_is_held()) {
 		if (e < s_e)
@@ -325,7 +348,8 @@ int mr_table_dump(struct mr_table *mrt, struct sk_buff *skb,
 next_entry:
 		e++;
 	}
-
+	rcu_read_unlock();
+	
 	spin_lock_bh(lock);
 	list_for_each_entry(mfc, &mrt->mfc_unres_queue, list) {
 		if (e < s_e)
-- 
2.43.0

[PATCH v3] net: ipmr: Fix out-of-bounds access i mr_mfc_uses_dev()

[Abdullah]

The issue was reported by Syzbot as an out-of-bounds read:
UBSAN: array-index-out-of-bounds in net/ipv4/ipmr_base.c:289:10
Index -772737152 is out of range for type 'const struct vif_device[32]'

The problem occurs when the minvif/maxvif values in the mr_mfc struct
become invalid (possibly due to memory corruption or uninitialized values).
This patch fixes the issue by ensuring proper boundary checks and rcu_read
locking before accessing vif_table[] in mr_mfc_uses_dev().

Fixes: <COMMIT_HASH>
Reported-by: syzbot+5cfae50c0e5f2c500013@syzkaller.appspotmail.com
Signed-off-by: Abdullah <asharji1828@gmail.com>
---
 net/ipv4/ipmr_base.c | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ipmr_base.c b/net/ipv4/ipmr_base.c
index 03b6eee407a2..7c38d0cf41fc 100644
--- a/net/ipv4/ipmr_base.c
+++ b/net/ipv4/ipmr_base.c
@@ -280,9 +280,31 @@ static bool mr_mfc_uses_dev(const struct mr_table *mrt,
 			    const struct mr_mfc *c,
 			    const struct net_device *dev)
 {
+	/**
+	* Helper function that checks if *dev is part of the OIL (Outgoing Interfaces List).
+	* @mrt: Is the multi-routing table.
+	* @c: Is the Multicast Forwarding Cache.
+	* @dev: The net device being checked.
+	*
+	* vif_dev: Pointer to the net device's struct.
+	* vif: Pointer to the actual device.
+	*
+	* OIL is a subset of mrt->vif_table[].
+	* minvif: Start index of OIL in vif_table[].
+	* maxvif: End index of OIL in vif_table[].
+	*
+	* Returns:
+	* - true if `dev` is part of the OIL.
+	* - false otherwise.
+	*/
+
 	int ct;
+	
+	int minvif = c->mfc_un.res.minvif, maxvif = c->mfc_un.res.maxvif;
+	if (minvif < 0 || maxvif > 32)
+		return false;
 
-	for (ct = c->mfc_un.res.minvif; ct < c->mfc_un.res.maxvif; ct++) {
+	for (ct = minvif; ct < maxvif; ct++) {
 		const struct net_device *vif_dev;
 		const struct vif_device *vif;
 
@@ -309,7 +331,8 @@ int mr_table_dump(struct mr_table *mrt, struct sk_buff *skb,
 
 	if (filter->filter_set)
 		flags |= NLM_F_DUMP_FILTERED;
-
+	
+	rcu_read_lock();
 	list_for_each_entry_rcu(mfc, &mrt->mfc_cache_list, list,
 				lockdep_rtnl_is_held()) {
 		if (e < s_e)
@@ -325,7 +348,8 @@ int mr_table_dump(struct mr_table *mrt, struct sk_buff *skb,
 next_entry:
 		e++;
 	}
-
+	rcu_read_unlock();
+	
 	spin_lock_bh(lock);
 	list_for_each_entry(mfc, &mrt->mfc_unres_queue, list) {
 		if (e < s_e)
-- 
2.43.0

Re: [PATCH v3] net: ipmr: Fix out-of-bounds access i mr_mfc_uses_dev()

[Jakub Kicinski]

On Wed, 29 Jan 2025 12:50:17 +0400 Abdullah wrote:
> The issue was reported by Syzbot as an out-of-bounds read:
> UBSAN: array-index-out-of-bounds in net/ipv4/ipmr_base.c:289:10
> Index -772737152 is out of range for type 'const struct vif_device[32]'
> 
> The problem occurs when the minvif/maxvif values in the mr_mfc struct
> become invalid (possibly due to memory corruption or uninitialized values).
> This patch fixes the issue by ensuring proper boundary checks and rcu_read
> locking before accessing vif_table[] in mr_mfc_uses_dev().
> 
> Fixes: <COMMIT_HASH>
> Reported-by: syzbot+5cfae50c0e5f2c500013@syzkaller.appspotmail.com
> Signed-off-by: Abdullah <asharji1828@gmail.com>

Could you explain what you're trying to do here?

Are you just tossing patches to test at syzbot? If yes, please remove
the unnecessary CCs, reply directly to the syzbot address, there is no
need to spam the mailing lists.

Or do you mean this as a real submissions? In which case why is there
<COMMIT_HASH> instead of the correct commit? The entire submission
feels a little.. LLM-aided.
-- 
pw-bot: cr