Re: [sctp] 327fecdaf3: BUG:kernel_NULL_pointer_dereference,address

[Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>]

On Mon, Nov 04, 2019 at 10:14:00PM +0800, Wei Zhao wrote:
> On 11/4/19, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> > On Mon, Nov 04, 2019 at 04:46:35PM +0800, kernel test robot wrote:
> >> [   35.312661] BUG: kernel NULL pointer dereference, address:
> >> 00000000000005d8
> >> [   35.316225] #PF: supervisor read access in kernel mode
> >> [   35.319178] #PF: error_code(0x0000) - not-present page
> >> [   35.322078] PGD 800000021b569067 P4D 800000021b569067 PUD 21b688067 PMD
> >> 0
> >> [   35.325629] Oops: 0000 [#1] SMP PTI
> >> [   35.327965] CPU: 0 PID: 3148 Comm: trinity-c5 Not tainted
> >> 5.4.0-rc3-01107-g327fecdaf39ab #12
> >> [   35.332863] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> >> 1.10.2-1 04/01/2014
> >> [   35.337932] RIP: 0010:sctp_packet_transmit+0x767/0x822
> >
> > Right, as asoc can be NULL by then. (per the check on it a few lines
> > before the change here).
> 
> Yes, apologize for missing the NULL check (Actually I realized some
> further check is need to correctly identify the first in flight
> packet, as outstanding_bytes has already been increased by this first
> in flight packet itself before getting into sctp_packet_transmit).
> 
> Anyway, I think I do not need further action, as the patch is anyway
> not going to be merged, the 0day robot picks up the patch from the
> mail list directly instead of git repo, right?

That's my understanding as well. I double checked and the patch wasn't
applied by Dave, so we're good.

Thanks,
Marcelo