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]
Message-ID: <20191104144909.GA15842@localhost.localdomain>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ