|
From: Dan C. <dan...@or...> - 2022-08-31 10:13:54
|
On Wed, Aug 31, 2022 at 10:48:54AM +0800, Hawkins Jiawei wrote: > Kernel will iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). > Because the ATTR_RECORDs are next to each other, kernel can get the next > ATTR_RECORD from end address of current ATTR_RECORD, through current > ATTR_RECORD length field. > > The problem is that during iteration, when kernel calculates the end address > of current ATTR_RECORD, kernel may trigger an overflow bug in > executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. This > may wrap, leading to a forever iteration on 32bit systems. > > This patch solves it by adding an overflow checking on calculating end address > of current ATTR_RECORD during iteration. > > Suggested-by: Dan Carpenter <dan...@or...> > Link: https://lore.kernel.org/all/20220827105842.GM2030@kadam/ > Signed-off-by: Hawkins Jiawei <yin...@gm...> > --- > fs/ntfs/attrib.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/ntfs/attrib.c b/fs/ntfs/attrib.c > index 904734e34507..55e618c9e63e 100644 > --- a/fs/ntfs/attrib.c > +++ b/fs/ntfs/attrib.c > @@ -617,6 +617,9 @@ static int ntfs_attr_find(const ATTR_TYPE type, const ntfschar *name, > return -ENOENT; > if (unlikely(!a->length)) > break; > + /* check for wrap around */ > + if ((u8 *)a + le32_to_cpu(a->length) < (u8 *)a) > + break; Wouldn't it also be good to check that a + a->length <= mrec_end? It gets checked on the next iteration sure, but it just seems like a reasonable thing to check here. regards, dan carpenter > if (a->type != type) > continue; > /* > -- > 2.25.1 > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syz...@go.... > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/7b8b8633d921665a717734d011a92f713944d0fb.1661875711.git.yin31149%40gmail.com. |
