Created attachment 156004 [details]
patch for geli
In g_eli_auth_run() and g_eli_crypto_run(), crypto_dispatch() sends crypto request.
After the last child bio is served, the bp is freed in g_vfs_done().
Then in g_eli_auth_run() and g_eli_crypto_run(), there are uses of the freed bp
if (bp->bio_error == 0)
bp->bio_error = error;
I believe this will in practice be rare - let me know if you agree:
> returns EINVAL if its argument or the callback function was NULL, and 0
So aside from bugs elsewhere, crypto_dispatch should only ever return 0, and we'd need a race with another thread that sets bp->bio_error in order to cause an issue.
(In reply to Ed Maste from comment #1)
Yes. I do believe this is a rare case in practice. :)
I run into this because I test tools/regression/geom_eli with memguard.
A commit references this bug:
Date: Thu Aug 6 17:13:35 UTC 2015
New revision: 286373
After crypto_dispatch() bio might be already delivered and destroyed,
so we cannot access it anymore. Setting an error later lead to memory
Assert that crypto_dispatch() was successful. It can fail only if we pass a
bogus crypto request, which is a bug in the program, not a runtime condition.
Submitted by: luke.tw
Reviewed by: emaste
MFC after: 3 days