netdev - Re: [sctp] 327fecdaf3: BUG:kernel_NULL_pointer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 4 Nov 2019 11:49:09 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Wei Zhao <wallyzhao@...il.com>
Cc:     kernel test robot <rong.a.chen@...el.com>, vyasevich@...il.com,
        nhorman@...driver.com, davem@...emloft.net,
        linux-sctp@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, wally.zhao@...ia-sbell.com,
        lkp@...ts.01.org
Subject: Re: [sctp] 327fecdaf3: BUG:kernel_NULL_pointer_dereference,address

On Mon, Nov 04, 2019 at 10:14:00PM +0800, Wei Zhao wrote:
> On 11/4/19, Marcelo Ricardo Leitner <marcelo.leitner@...il.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