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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFRmqq6vNg5sBYp7voT4SoVR+i+L8fDqUUZOF68cRdcKkQcZmw@mail.gmail.com>
Date:   Mon, 4 Nov 2019 22:14:00 +0800
From:   Wei Zhao <wallyzhao@...il.com>
To:     Marcelo Ricardo Leitner <marcelo.leitner@...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 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?

Thanks a lot,
Wally

>
>   Marcelo
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ