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  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]
Date:	Tue, 21 Jun 2016 20:55:02 -0400
From:	Josh Boyer <>
To:	Linus Torvalds <>
Cc:	"Martin K. Petersen" <>,
	Johannes Thumshirn <>,
	Thorsten Leemhuis <>,
	Linux Kernel Mailing List <>
Subject: Re: Reported regressions for 4.7 as of Sunday, 2016-06-19

On Tue, Jun 21, 2016 at 4:40 PM, Linus Torvalds
<> wrote:
> On Tue, Jun 21, 2016 at 4:11 AM, Josh Boyer <> wrote:
>> On Sun, Jun 19, 2016 at 10:52 AM, Thorsten Leemhuis
>> <> wrote:
>>> Description:    BUG: unable to handle kernel NULL pointer dereference […] qla24xx_process_response_queue+0x49/0x4b0 [qla2xxx]
>>> Report:
>>> Latest status:  n/a
>>> Date rep/stat:  2016-06-14 / n/a
>>> Notes:          poked bugzilla, a bit unsure how to proceed
>> We have two bug reports against 4.5.5 - 4.5.7 of this as well.  So
>> whatever commit caused this in 4.7 seems to have been pulled into the
>> 4.5.y stable tree.  I suspect it is in the 4.6.y stable tree as well,
>> but we don't have that pushed out yet.
> That seems pretty unambiguous - 4.5.5 is fine, and 4.5.6 is bad. So
> unless it's specific to whatever patches RH is carrying around, we
> should be able to just look at the scsi-related stable tree patches in
> that region. That seems simple enough.

I thought the same.  We're only carrying one very very old scsi patch
to revalidate a pointer.  That shouldn't even been involved in this
path and upstream 4.7-rcX is hitting the same issue anyway.  Thus far
we've only seen reports for qla2xxx devices as far as I'm aware.

> But theres' really only two (trivial) patches in there:
>  - scsi: Add intermediate STARGET_REMOVE state to scsi_target_state
>    (f05795d3d771f30a7bdc3a138bf714b06d42aa95 upstream)
>  - Revert "scsi: fix soft lockup in scsi_remove_target() on module removal"
>    (305c2e71b3d733ec065cb716c76af7d554bd5571 upstream)
> as far as I can tell. And neither of them looks very likely, but what
> do I know. Adding Martin Petersen and Johannes Thumshirn to the
> participants just in case they go "Ahh.."

Right, I had the same head scratching.


Powered by blists - more mailing lists