Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Aug 2015 05:11:57 +0200
From:      Pawel Jakub Dawidek <pjd@FreeBSD.org>
To:        Ed Maste <emaste@freebsd.org>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: Memory modified after free, seemingly geli related
Message-ID:  <20150806031157.GA1116@garage.freebsd.pl>
In-Reply-To: <20150806020639.GA72832@garage.freebsd.pl>
References:  <CAPyFy2B3hN3z%2BTonbCDiKPxL5v53ZTtms1BXZgdofWzDzZ4X0A@mail.gmail.com> <20150806020639.GA72832@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help

--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 06, 2015 at 04:06:40AM +0200, Pawel Jakub Dawidek wrote:
> On Wed, Aug 05, 2015 at 03:24:26AM +0000, Ed Maste wrote:
> > I've encountered a few memory modified after free panics recently,
> > which seem to be from geli. I don't yet have any debugging to
> > completely confirm it's geli, but it has not happened on my other test
> > laptop which configured similarly but without geli.
> >=20
> > This has a few local patches from my to-commit-to-HEAD queue.
> > FreeBSD volta 11.0-CURRENT FreeBSD 11.0-CURRENT #10
> > r284409+6a002d9(staging): Tue Jul  7 17:57:01 EDT 2015
> >=20
> > panic: Memory modified after free 0xfffff80009d504d8(248) val=3D0 @
> > 0xfffff80009d50518
>=20
> I'm seeing it too. I tracked it down to ZFS. The bio was last owned by
> the ZFS::VDEV GEOM class, which is modyfing bio_error on freed bio. I'm
> investigating further and will let you know here once I find the
> cause.

Ok. It was bio from ZFS in my case, but it was GELI which modified
bio_error after delivering bio.

This patch fixes the race:

	http://people.freebsd.org/~pjd/patches/geom_eli.patch

Using bio after calling crypto_dispatch() is a bug. 'done' callbacks
might have already called g_io_deliver() and upper layer might have
already freed the bio.

I'm not fully convinced that panic is the right response to
crypto_dispatch() failure. It means that the driver failed our request
and didn't call our callback, which is bad as we never complete the I/O.
The crypto drivers tend to return errors only if the request itself is
bogus, but that is program's bug and not a runtime condition. In other
words panic should be fine here.

--=20
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com

--cWoXeonUoKmBZSoM
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVwtB8AAoJEJVLhSuxKFt1hskQAM+kFb9+WyRSbbGuJFgtLoIz
SbP8LDCo59z6Tj+U4CbB8LtIWn2iN2v5CXX59eZvWeU175mfcZN2H4z6nBdcFFB8
ZmYzR5ua8a1WGgjs3npxfZsZDrntteVA/j4Xf4SwW4pvtjwYGzyPDKTjjXcsXSQU
UK8JV0yfn5M5yweDP17ghgFnk5z3lr1iFPvCjrg/VRjHds9LDT864gmpLYc+mTHU
WLByFEA5rHO7+9ZKY0SqGxU9hLCQ1FpgicGnUK/tbNd6uTxR5fILrLZ40TPkkDXx
HlQ8cCrj88PxQY/dkB52RxR3t/DM9IqswM8lsLz2iuzkYoBeAWQFyM9WilXNZfbS
hitwze2uRGY5roZZRxfdykL9W5IEy0gAm3A8OeBod+VA0a6W4KMSuMC8osv9bHtR
RBDSwqUlzKIHjU3sODl/GDDL130HRj4IinVjdh0pcCUaSbDf2HdNPHwEv7g5YMtH
jJJOCqD9OI+bf8CkDaiUh3ahn2WA176R1QrDQVXYDEOZLiBrj8F89S95iT20SPD8
SFWfgTtfjW46m3dIItKJYu0QmdwRXl98gpNb2dQGRp22MBED8aNvDhkqshC2CZ0u
gRuH+N1btFBXFaNgW0A05kCtJ+TX50Ydfedbd4CCCi33+EPV3CWKbbf925zoonaR
tPrUnrlmVpoBhF7PmVoT
=rfyX
-----END PGP SIGNATURE-----

--cWoXeonUoKmBZSoM--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150806031157.GA1116>