From: Corey Minyard <minyard@acm.org>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: linux-sctp@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Oops on current Raspian when closing an SCTP connection
Date: Mon, 17 Aug 2020 18:28:44 +0000 [thread overview]
Message-ID: <20200817182844.GZ2842@minyard.net> (raw)
In-Reply-To: <20200817134457.GG3399@localhost.localdomain>
On Mon, Aug 17, 2020 at 10:44:57AM -0300, Marcelo Ricardo Leitner wrote:
> On Sun, Aug 16, 2020 at 06:06:24PM -0500, Corey Minyard wrote:
> > I'm seeing the following when an SCTP connection terminates. This is on
> > Raspian on a Raspberry Pi, version is Linux version 5.4.51-v7+. That's
> > 32-bit ARM.
> >
> > I haven't looked into it yet, I thought I would report before trying to
> > chase anything down. I'm not seeing it on 5.4 x86_64 systems.
> >
> > Aug 16 17:59:01 access kernel: [510640.438008] Hardware name: BCM2835
> > Aug 16 17:59:01 access kernel: [510640.443823] PC is at sctp_ulpevent_free+0x38/0xa0 [sctp]
> > Aug 16 17:59:01 access kernel: [510640.451498] LR is at sctp_queue_purge_ulpevents+0x34/0x50 [sctp]
>
> Not ringing a bell here. Can you pinpoint on which line this crash
> was? It seems, by the 0x8 offset and these function offsets, that this
> could be when it was trying to access event->rmem_len, but if event
> was NULL then it should have crashed earlier.
>
> Marcelo
I think so:
00015e38 <sctp_ulpevent_free>:
15e38: e1a0c00d mov ip, sp
15e3c: e92dd878 push {r3, r4, r5, r6, fp, ip, lr, pc}
15e40: e24cb004 sub fp, ip, #4
15e44: e52de004 push {lr} ; (str lr, [sp, #-4]!)
15e48: ebfffffe bl 0 <__gnu_mcount_nc>
ulpevent.c:1102 if (sctp_ulpevent_is_notification(event))
15e4c: e1d032f0 ldrsh r3, [r0, #32]
15e50: e1a05000 mov r5, r0
15e54: e3530000 cmp r3, #0
15e58: ba000011 blt 15ea4 <sctp_ulpevent_free+0x6c>
This is the false branch from the above (high bit isn't set).
ulpevent.c:1061 if (!skb->data_len) (just the fetch part)
15e5c: e5903040 ldr r3, [r0, #64] ; 0x40
ulpevent.c:1059 len = skb->len;
15e60: e590603c ldr r6, [r0, #60] ; 0x3c
ulpevent.c:1061 if (!skb->data_len) (the compare part)
15e64: e3530000 cmp r3, #0
15e68: 0a000008 beq 15e90 <sctp_ulpevent_free+0x58>
ulpevent.c:1065 skb_walk_frags(skb, frag) {
skbuff.h:1395 return skb->end; (inside skb_shinfo())
15e6c: e5903084 ldr r3, [r0, #132] ; 0x84
skbuff.h:3461 iter = skb_shinfo(skb)->frag_list
15e70: e5934008 ldr r4, [r3, #8] <-- Crash occurs here
15e74: e3540000 cmp r4, #0
15e78: 0a000004 beq 15e90 <sctp_ulpevent_free+0x58>
15e7c: e2840018 add r0, r4, #24
15e80: ebfffa34 bl 14758 <sctp_ulpevent_release_frag_data>
So it appears that skb->end is NULL.
-corey
WARNING: multiple messages have this Message-ID (diff)
From: Corey Minyard <minyard@acm.org>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: linux-sctp@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Oops on current Raspian when closing an SCTP connection
Date: Mon, 17 Aug 2020 13:28:44 -0500 [thread overview]
Message-ID: <20200817182844.GZ2842@minyard.net> (raw)
In-Reply-To: <20200817134457.GG3399@localhost.localdomain>
On Mon, Aug 17, 2020 at 10:44:57AM -0300, Marcelo Ricardo Leitner wrote:
> On Sun, Aug 16, 2020 at 06:06:24PM -0500, Corey Minyard wrote:
> > I'm seeing the following when an SCTP connection terminates. This is on
> > Raspian on a Raspberry Pi, version is Linux version 5.4.51-v7+. That's
> > 32-bit ARM.
> >
> > I haven't looked into it yet, I thought I would report before trying to
> > chase anything down. I'm not seeing it on 5.4 x86_64 systems.
> >
> > Aug 16 17:59:01 access kernel: [510640.438008] Hardware name: BCM2835
> > Aug 16 17:59:01 access kernel: [510640.443823] PC is at sctp_ulpevent_free+0x38/0xa0 [sctp]
> > Aug 16 17:59:01 access kernel: [510640.451498] LR is at sctp_queue_purge_ulpevents+0x34/0x50 [sctp]
>
> Not ringing a bell here. Can you pinpoint on which line this crash
> was? It seems, by the 0x8 offset and these function offsets, that this
> could be when it was trying to access event->rmem_len, but if event
> was NULL then it should have crashed earlier.
>
> Marcelo
I think so:
00015e38 <sctp_ulpevent_free>:
15e38: e1a0c00d mov ip, sp
15e3c: e92dd878 push {r3, r4, r5, r6, fp, ip, lr, pc}
15e40: e24cb004 sub fp, ip, #4
15e44: e52de004 push {lr} ; (str lr, [sp, #-4]!)
15e48: ebfffffe bl 0 <__gnu_mcount_nc>
ulpevent.c:1102 if (sctp_ulpevent_is_notification(event))
15e4c: e1d032f0 ldrsh r3, [r0, #32]
15e50: e1a05000 mov r5, r0
15e54: e3530000 cmp r3, #0
15e58: ba000011 blt 15ea4 <sctp_ulpevent_free+0x6c>
This is the false branch from the above (high bit isn't set).
ulpevent.c:1061 if (!skb->data_len) (just the fetch part)
15e5c: e5903040 ldr r3, [r0, #64] ; 0x40
ulpevent.c:1059 len = skb->len;
15e60: e590603c ldr r6, [r0, #60] ; 0x3c
ulpevent.c:1061 if (!skb->data_len) (the compare part)
15e64: e3530000 cmp r3, #0
15e68: 0a000008 beq 15e90 <sctp_ulpevent_free+0x58>
ulpevent.c:1065 skb_walk_frags(skb, frag) {
skbuff.h:1395 return skb->end; (inside skb_shinfo())
15e6c: e5903084 ldr r3, [r0, #132] ; 0x84
skbuff.h:3461 iter = skb_shinfo(skb)->frag_list
15e70: e5934008 ldr r4, [r3, #8] <-- Crash occurs here
15e74: e3540000 cmp r4, #0
15e78: 0a000004 beq 15e90 <sctp_ulpevent_free+0x58>
15e7c: e2840018 add r0, r4, #24
15e80: ebfffa34 bl 14758 <sctp_ulpevent_release_frag_data>
So it appears that skb->end is NULL.
-corey
next prev parent reply other threads:[~2020-08-17 18:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-16 23:06 Oops on current Raspian when closing an SCTP connection Corey Minyard
2020-08-16 23:06 ` Corey Minyard
2020-08-17 13:44 ` Marcelo Ricardo Leitner
2020-08-17 13:44 ` Marcelo Ricardo Leitner
2020-08-17 18:28 ` Corey Minyard [this message]
2020-08-17 18:28 ` Corey Minyard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200817182844.GZ2842@minyard.net \
--to=minyard@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=marcelo.leitner@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.