BUG: corrupted list in cpu_stop_queue_work

Commit Message

Tetsuo Handa July 9, 2018, 12:55 p.m. UTC

Hello Matthew,

It seems to me that there are other locations which do not check xas_store()
failure. Is that really OK? If they are OK, I think we want a comment like
/* This never fails. */ or /* Failure is OK because ... */
for each call without failure check.



From d6f24d6eecd79836502527624f8086f4e3e4c331 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <[e-mail]>
Date: Mon, 9 Jul 2018 15:58:44 +0900
Subject: [PATCH] shmem: Fix crash upon xas_store() failure.

syzbot is reporting list corruption [1]. This is because xas_store() from
shmem_add_to_page_cache() is not handling memory allocation failure. Fix
this by checking xas_error() after xas_store().

[1] https://syzkaller.appspot.com/bug?id=ccf34b892706ff6f3321da526329476eab23d5a0

Signed-off-by: Tetsuo Handa <[e-mail]>
Reported-by: [e-mail]
Fixes: "shmem: Convert shmem_add_to_page_cache to XArray"
---
 mm/shmem.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Matthew Wilcox July 9, 2018, 1:32 p.m. UTC | #1

On Mon, Jul 09, 2018 at 09:55:17PM +0900, Tetsuo Handa wrote:
> Hello Matthew,
> 
> It seems to me that there are other locations which do not check xas_store()
> failure. Is that really OK? If they are OK, I think we want a comment like
> /* This never fails. */ or /* Failure is OK because ... */
> for each call without failure check.

Good grief, no, I'm not adding a comment to all 50 calls to
xas_store().  Here are some rules:

 - xas_store(NULL) cannot fail.
 - xas_store(p) cannot fail if we know something was already in
   that slot beforehand (ie a replace operation).
 - xas_store(p) cannot fail if xas_create_range() was previously
   successful.
 - xas_store(p) can fail, but it's OK if the only things after that are
   other xas_*() calls.  Because every xas_*() call checks xas_error().
   So this is fine:

	do {
		xas_store(&xas, p);
		xas_set_tag(&xas, XA_TAG_0);
	} while (xas_nomem(&xas, GFP_KERNEL));

> >From d6f24d6eecd79836502527624f8086f4e3e4c331 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <[e-mail]>
> Date: Mon, 9 Jul 2018 15:58:44 +0900
> Subject: [PATCH] shmem: Fix crash upon xas_store() failure.
> 
> syzbot is reporting list corruption [1]. This is because xas_store() from
> shmem_add_to_page_cache() is not handling memory allocation failure. Fix
> this by checking xas_error() after xas_store().

I have no idea why you wrote this patch on Monday when I already said
I knew what the problem was on Friday, fixed the problem and pushed it
out to my git tree on Saturday.

Tetsuo Handa July 9, 2018, 2:15 p.m. UTC | #2

On 2018/07/09 22:32, Matthew Wilcox wrote:
>> >From d6f24d6eecd79836502527624f8086f4e3e4c331 Mon Sep 17 00:00:00 2001
>> From: Tetsuo Handa <[e-mail]>
>> Date: Mon, 9 Jul 2018 15:58:44 +0900
>> Subject: [PATCH] shmem: Fix crash upon xas_store() failure.
>>
>> syzbot is reporting list corruption [1]. This is because xas_store() from
>> shmem_add_to_page_cache() is not handling memory allocation failure. Fix
>> this by checking xas_error() after xas_store().
> 
> I have no idea why you wrote this patch on Monday when I already said
> I knew what the problem was on Friday, fixed the problem and pushed it
> out to my git tree on Saturday.
> 

Because syzbot found a C reproducer on 2018/07/09 02:29 UTC, and your fix was
not in time for a kernel version syzbot was testing, and you were not listed
as a recipient of this bug, and I didn't know you already fixed this bug.

Anyway, linux-next-20180709 still does not have this fix.
What is the title of your fix you pushed on Saturday?

Matthew Wilcox July 9, 2018, 2:24 p.m. UTC | #3

On Mon, Jul 09, 2018 at 11:15:54PM +0900, Tetsuo Handa wrote:
> On 2018/07/09 22:32, Matthew Wilcox wrote:
> >> >From d6f24d6eecd79836502527624f8086f4e3e4c331 Mon Sep 17 00:00:00 2001
> >> From: Tetsuo Handa <[e-mail]>
> >> Date: Mon, 9 Jul 2018 15:58:44 +0900
> >> Subject: [PATCH] shmem: Fix crash upon xas_store() failure.
> >>
> >> syzbot is reporting list corruption [1]. This is because xas_store() from
> >> shmem_add_to_page_cache() is not handling memory allocation failure. Fix
> >> this by checking xas_error() after xas_store().
> > 
> > I have no idea why you wrote this patch on Monday when I already said
> > I knew what the problem was on Friday, fixed the problem and pushed it
> > out to my git tree on Saturday.
> > 
> 
> Because syzbot found a C reproducer on 2018/07/09 02:29 UTC, and your fix was
> not in time for a kernel version syzbot was testing, and you were not listed
> as a recipient of this bug, and I didn't know you already fixed this bug.
> 
> Anyway, linux-next-20180709 still does not have this fix.
> What is the title of your fix you pushed on Saturday?

I folded it into shmem: Convert shmem_add_to_page_cache to XArray.
I can see it's fixed in today's linux-next.  I fixed it differently
from the way you fixed it, so if you're looking for an xas_error check
after xas_store, you won't find it.

Tetsuo Handa July 9, 2018, 2:34 p.m. UTC | #4

On 2018/07/09 23:24, Matthew Wilcox wrote:
>> Anyway, linux-next-20180709 still does not have this fix.
>> What is the title of your fix you pushed on Saturday?
> 
> I folded it into shmem: Convert shmem_add_to_page_cache to XArray.
> I can see it's fixed in today's linux-next.  I fixed it differently
> from the way you fixed it, so if you're looking for an xas_error check
> after xas_store, you won't find it.
> 

OK. linux-next-20180709 should no longer hit this bug. Closing with

#syz fix: shmem: Convert shmem_add_to_page_cache to XArray

Thanks.

Patch

diff --git a/mm/shmem.c b/mm/shmem.c
index 0f151c8..382aeb3 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -606,6 +606,8 @@  static int shmem_add_to_page_cache(struct page *page,
 		}
 next:
 		xas_store(&xas, page + i);
+		if (xas_error(&xas))
+			goto unlock;
 		if (++i < nr) {
 			xas_next(&xas);
 			goto next;