* [PATCH v2 net 1/1] rose: check NULL rose_loopback_neigh->loopback
@ 2022-08-18 0:02 Francois Romieu
2022-08-22 13:30 ` patchwork-bot+netdevbpf
2022-08-25 18:17 ` Eric Dumazet
0 siblings, 2 replies; 4+ messages in thread
From: Francois Romieu @ 2022-08-18 0:02 UTC (permalink / raw
To: netdev
Cc: linux-hams, Bernard, Bernard Pidoux, Thomas Osterried,
David S . Miller, Jakub Kicinski, Paolo Abeni, Eric Dumazet
From: Bernard Pidoux <f6bvp@free.fr>
Commit 3b3fd068c56e3fbea30090859216a368398e39bf added NULL check for
`rose_loopback_neigh->dev` in rose_loopback_timer() but omitted to
check rose_loopback_neigh->loopback.
It thus prevents *all* rose connect.
The reason is that a special rose_neigh loopback has a NULL device.
/proc/net/rose_neigh illustrates it via rose_neigh_show() function :
[...]
seq_printf(seq, "%05d %-9s %-4s %3d %3d %3s %3s %3lu %3lu",
rose_neigh->number,
(rose_neigh->loopback) ? "RSLOOP-0" : ax2asc(buf, &rose_neigh->callsign),
rose_neigh->dev ? rose_neigh->dev->name : "???",
rose_neigh->count,
/proc/net/rose_neigh displays special rose_loopback_neigh->loopback as
callsign RSLOOP-0:
addr callsign dev count use mode restart t0 tf digipeaters
00001 RSLOOP-0 ??? 1 2 DCE yes 0 0
By checking rose_loopback_neigh->loopback, rose_rx_call_request() is called
even in case rose_loopback_neigh->dev is NULL. This repairs rose connections.
Verification with rose client application FPAC:
FPAC-Node v 4.1.3 (built Aug 5 2022) for LINUX (help = h)
F6BVP-4 (Commands = ?) : u
Users - AX.25 Level 2 sessions :
Port Callsign Callsign AX.25 state ROSE state NetRom status
axudp F6BVP-5 -> F6BVP-9 Connected Connected ---------
Fixes: 3b3fd068c56e ("rose: Fix Null pointer dereference in rose_send_frame()")
Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
Suggested-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Thomas DL9SAU Osterried <thomas@osterried.de>
---
Regression appeared in the v5.9..v5.10 cycle. The fix above also applies as-is
to stable v5.4, stable v4.19 and stable v4.14.
net/rose/rose_loopback.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
index 11c45c8c6c16..036d92c0ad79 100644
--- a/net/rose/rose_loopback.c
+++ b/net/rose/rose_loopback.c
@@ -96,7 +96,8 @@ static void rose_loopback_timer(struct timer_list *unused)
}
if (frametype == ROSE_CALL_REQUEST) {
- if (!rose_loopback_neigh->dev) {
+ if (!rose_loopback_neigh->dev &&
+ !rose_loopback_neigh->loopback) {
kfree_skb(skb);
continue;
}
--
2.37.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2 net 1/1] rose: check NULL rose_loopback_neigh->loopback
2022-08-18 0:02 [PATCH v2 net 1/1] rose: check NULL rose_loopback_neigh->loopback Francois Romieu
@ 2022-08-22 13:30 ` patchwork-bot+netdevbpf
2022-08-25 18:17 ` Eric Dumazet
1 sibling, 0 replies; 4+ messages in thread
From: patchwork-bot+netdevbpf @ 2022-08-22 13:30 UTC (permalink / raw
To: Francois Romieu
Cc: netdev, linux-hams, bernard.f6bvp, f6bvp, thomas, davem, kuba,
pabeni, edumazet
Hello:
This patch was applied to netdev/net.git (master)
by David S. Miller <davem@davemloft.net>:
On Thu, 18 Aug 2022 02:02:13 +0200 you wrote:
> From: Bernard Pidoux <f6bvp@free.fr>
>
> Commit 3b3fd068c56e3fbea30090859216a368398e39bf added NULL check for
> `rose_loopback_neigh->dev` in rose_loopback_timer() but omitted to
> check rose_loopback_neigh->loopback.
>
> It thus prevents *all* rose connect.
>
> [...]
Here is the summary with links:
- [v2,net,1/1] rose: check NULL rose_loopback_neigh->loopback
https://git.kernel.org/netdev/net/c/3c53cd65dece
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2 net 1/1] rose: check NULL rose_loopback_neigh->loopback
2022-08-18 0:02 [PATCH v2 net 1/1] rose: check NULL rose_loopback_neigh->loopback Francois Romieu
2022-08-22 13:30 ` patchwork-bot+netdevbpf
@ 2022-08-25 18:17 ` Eric Dumazet
2022-08-26 0:02 ` Francois Romieu
1 sibling, 1 reply; 4+ messages in thread
From: Eric Dumazet @ 2022-08-25 18:17 UTC (permalink / raw
To: Francois Romieu
Cc: netdev, linux-hams, Bernard, Bernard Pidoux, Thomas Osterried,
David S . Miller, Jakub Kicinski, Paolo Abeni
On Wed, Aug 17, 2022 at 5:02 PM Francois Romieu <romieu@fr.zoreil.com> wrote:
>
> From: Bernard Pidoux <f6bvp@free.fr>
>
> Commit 3b3fd068c56e3fbea30090859216a368398e39bf added NULL check for
> `rose_loopback_neigh->dev` in rose_loopback_timer() but omitted to
> check rose_loopback_neigh->loopback.
>
> It thus prevents *all* rose connect.
>
> The reason is that a special rose_neigh loopback has a NULL device.
>
> /proc/net/rose_neigh illustrates it via rose_neigh_show() function :
> [...]
> seq_printf(seq, "%05d %-9s %-4s %3d %3d %3s %3s %3lu %3lu",
> rose_neigh->number,
> (rose_neigh->loopback) ? "RSLOOP-0" : ax2asc(buf, &rose_neigh->callsign),
> rose_neigh->dev ? rose_neigh->dev->name : "???",
> rose_neigh->count,
>
> /proc/net/rose_neigh displays special rose_loopback_neigh->loopback as
> callsign RSLOOP-0:
>
> addr callsign dev count use mode restart t0 tf digipeaters
> 00001 RSLOOP-0 ??? 1 2 DCE yes 0 0
>
> By checking rose_loopback_neigh->loopback, rose_rx_call_request() is called
> even in case rose_loopback_neigh->dev is NULL. This repairs rose connections.
>
> Verification with rose client application FPAC:
>
> FPAC-Node v 4.1.3 (built Aug 5 2022) for LINUX (help = h)
> F6BVP-4 (Commands = ?) : u
> Users - AX.25 Level 2 sessions :
> Port Callsign Callsign AX.25 state ROSE state NetRom status
> axudp F6BVP-5 -> F6BVP-9 Connected Connected ---------
>
> Fixes: 3b3fd068c56e ("rose: Fix Null pointer dereference in rose_send_frame()")
> Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
> Suggested-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Thomas DL9SAU Osterried <thomas@osterried.de>
> ---
>
> Regression appeared in the v5.9..v5.10 cycle. The fix above also applies as-is
> to stable v5.4, stable v4.19 and stable v4.14.
>
> net/rose/rose_loopback.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> index 11c45c8c6c16..036d92c0ad79 100644
> --- a/net/rose/rose_loopback.c
> +++ b/net/rose/rose_loopback.c
> @@ -96,7 +96,8 @@ static void rose_loopback_timer(struct timer_list *unused)
> }
>
> if (frametype == ROSE_CALL_REQUEST) {
> - if (!rose_loopback_neigh->dev) {
> + if (!rose_loopback_neigh->dev &&
> + !rose_loopback_neigh->loopback) {
> kfree_skb(skb);
> continue;
> }
> --
> 2.37.1
ok but then the original crash/bug reappears....
general protection fault, probably for non-canonical address
0xdffffc000000006c: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000360-0x0000000000000367]
CPU: 0 PID: 3587 Comm: udevd Not tainted
6.0.0-rc1-syzkaller-00228-g0c4a95417ee4 #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 07/22/2022
RIP: 0010:ax25_dev_ax25dev include/net/ax25.h:342 [inline]
RIP: 0010:ax25_send_frame+0xe4/0x640 net/ax25/ax25_out.c:56
Code: 00 48 85 c0 49 89 c4 0f 85 fb 03 00 00 e8 94 4f 2c f9 49 8d bd
60 03 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c
02 00 0f 85 b1 04 00 00 4d 8b ad 60 03 00 00 4d 85 ed 0f 84
RSP: 0018:ffffc90000007ab8 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: ffff888026306c08 RCX: 0000000000000100
RDX: 000000000000006c RSI: ffffffff884fbbbc RDI: 0000000000000360
RBP: ffffffff9155a560 R08: 0000000000000001 R09: ffffffff908dda67
R10: 0000000000000001 R11: 1ffffffff2012bb1 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000104 R15: 0000000000000000
FS: 00007feeaa097840(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f831856a1b8 CR3: 000000007bd4f000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
rose_send_frame+0xcc/0x2f0 net/rose/rose_link.c:106
rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255
rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009
rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111
call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474
expire_timers kernel/time/timer.c:1519 [inline]
__run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
__run_timers kernel/time/timer.c:1768 [inline]
run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
__do_softirq+0x1d3/0x9c6 kernel/softirq.c:571
invoke_softirq kernel/softirq.c:445 [inline]
__irq_exit_rcu+0x123/0x180 kernel/softirq.c:650
irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
sysvec_apic_timer_interrupt+0x93/0xc0 arch/x86/kernel/apic/apic.c:1106
</IRQ>
<TASK>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2 net 1/1] rose: check NULL rose_loopback_neigh->loopback
2022-08-25 18:17 ` Eric Dumazet
@ 2022-08-26 0:02 ` Francois Romieu
0 siblings, 0 replies; 4+ messages in thread
From: Francois Romieu @ 2022-08-26 0:02 UTC (permalink / raw
To: Eric Dumazet
Cc: netdev, linux-hams, Bernard, Bernard Pidoux, Thomas Osterried,
David S . Miller, Jakub Kicinski, Paolo Abeni
Eric Dumazet <edumazet@google.com> :
[...]
> ok but then the original crash/bug reappears....
When the fuzzer runs, the system does not notice that something goes
wrong until rose_find_listener() returns NULL in rose_rx_call_request
whereas Bernard's connect passes this test.
Testing both sk == NULL and !neigh->dev after rose_find_listener may
work but it looks like an ugly bandaid.
Good night.
--
Ueimor
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-08-26 0:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-08-18 0:02 [PATCH v2 net 1/1] rose: check NULL rose_loopback_neigh->loopback Francois Romieu
2022-08-22 13:30 ` patchwork-bot+netdevbpf
2022-08-25 18:17 ` Eric Dumazet
2022-08-26 0:02 ` Francois Romieu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).