linux-kernel - Linux >= 4.2 dm_any_congested bug due to bad data from vfs/mm? [was: Bug in dm_any

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>] [day] [month] [year] [list]

Date:	Tue, 10 Nov 2015 12:27:41 -0500
From:	Mike Snitzer <snitzer@...hat.com>
To:	Boštjan Škufca @ Teon.si <bostjan@...n.si>
Cc:	device-mapper development <dm-devel@...hat.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Linux >= 4.2 dm_any_congested bug due to bad data from vfs/mm? [was:
 Bug in dm_any_congested?]

[Cc'ing LKML and linux-fsdevel to cast a wider net and raise awareness]

On Tue, Nov 10 2015 at 10:02am -0500,
Boštjan Škufca @ Teon.si <bostjan@...n.si> wrote:

> On 10 November 2015 at 15:39, Zdenek Kabelac <zkabelac@...hat.com> wrote:
> > Dne 10.11.2015 v 14:14 Boštjan Škufca @ Teon.si napsal(a):
> >>
> >> Hi all,
> >>
> >> HW is a bit dated, but had no problems with it up to now, and SW raid
> >> is used here. Kernel was 4.2.4.
> >>
> >> Is this the right mlist for such bug?
> >
> >
> > Hi
> >
> > Yes the issue is known - but source is not fully known.
> > I've opened public BZ: https://bugzilla.redhat.com/1279941
> > There is some potential fix - but unclear what it solves:
> > http://git.kernel.org/linus/ad5f498f610
> 
> So 4.1.13 is ok in this respect, or is this unknown ATM?
> 
> Does it depend on underlying storage at all, or not? MD does not seem
> to be listed in stack trace.

We don't yet have a reliable reproducer.  So if your test proves to
reliably reproduce the issue for you then we may be able to make much
quicker progress.

While the bug manifests as a crash in dm_any_congested (either NULL
pointer or GPF) it _seems_ that the problem is further up the stack in
the vfs and/or mm (by passing garbage into dm_any_congested via call to
queue->backing_dev_info.congested_fn).  But all possibilities are still
on the table... again not much to go on yet.

Please feel free to test using the 4.4 stable@ commit Zdenek referenced
(but I'm skeptical it'll fix this issue if you aren't reactivating
volumes or anything): http://git.kernel.org/linus/ad5f498f610

Also, you're welcome to update this BZ as you collect additional info:
https://bugzilla.redhat.com/1279941

Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/