[dm-devel] FW: RE:(2) FW: RE: FW: (2) FW: Use-after-free while dm-verity

[Mike Snitzer]

On Tue, Aug 21 2018 at  5:38am -0400,
Gilad Ben-Yossef <gilad at benyossef.com> wrote:

> Hi,
> 
> On Mon, Aug 20, 2018 at 2:33 PM, 정혜연 <hyeon.chung at samsung.com> wrote:
> >
> > Dear Gilad,
> >
> >
> >
> > We found memcopy is not preempted as you explained.
> >
> > Memcopy make kernel panic at the very first time.
> >
> > Your comment was very helpful us to find this. Thank you.
> >
> >
> 
> 
> I'm glad I could help.
> 
> >
> > We found the other core executed shrink_node at that time, so we suspect that lowmem situation coulde make this problem.
> >
> > And we tested after reverting async patch for 3 days and there's no isuue so far.
> >
> > So we assume there's unexpected free in dm-verity or some page memory operation (ex. offset ?).
> >
> >
> >
> > Do you have any idea?
> >
> >
> 
> 
> One thing that comes to mind is understanding why there are data
> errors in the data being read. The stack trace you sent shows calls to
> verity_fec_decode().
> This would happen if there was a mismatch between the computed hash
> and the expected hash of (in this specific case per the stack trace) a
> storage block containing hashes for the data. It is therefore attempts
> to fix the errors via employing Read Solomon codes.
> 
> While it is part of DM-Verity design, I'm surprised to see this happen
> in a lab environment. Do you deliberately create 1 bit errors in the
> data as a test or is this some coincidence?
> 
> Other than that, I return to my previous request:
> 
> "If this doesn't bring anything to light, please provide a the full
> kernel panic log (not just the snippet here), your kernel config and
> what architecture/board you are running this on, as well as details
> about DM-verity partition setup, size and underlying storage so I may
> attempt to recreate this."
> 
> 
> This will best help me help you.

Can you please see if this patch helps?

https://patchwork.kernel.org/patch/10573051/

Thanks,
Mike