From b2cbb0712b8939ea9eae21e24cafe1334feaaac5 Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Sat, 1 Aug 2020 17:58:02 -0400 Subject: [PATCH] Fixes for 4.9 Signed-off-by: Sasha Levin --- ...t-p9_read_work-if-req-status-changed.patch | 66 ++++++++ ...concurrency-del-of-req_list-in-p9_fd.patch | 69 ++++++++ ...eger-underflow-at-struct-fbcon_ops-c.patch | 157 ++++++++++++++++++ queue-4.9/series | 5 + ...x-truncated-.bss-with-fdata-sections.patch | 54 ++++++ ...page-align-end-of-.page_aligned-sect.patch | 84 ++++++++++ 6 files changed, 435 insertions(+) create mode 100644 queue-4.9/9p-trans_fd-abort-p9_read_work-if-req-status-changed.patch create mode 100644 queue-4.9/9p-trans_fd-fix-concurrency-del-of-req_list-in-p9_fd.patch create mode 100644 queue-4.9/fbdev-detect-integer-underflow-at-struct-fbcon_ops-c.patch create mode 100644 queue-4.9/x86-build-lto-fix-truncated-.bss-with-fdata-sections.patch create mode 100644 queue-4.9/x86-vmlinux.lds-page-align-end-of-.page_aligned-sect.patch diff --git a/queue-4.9/9p-trans_fd-abort-p9_read_work-if-req-status-changed.patch b/queue-4.9/9p-trans_fd-abort-p9_read_work-if-req-status-changed.patch new file mode 100644 index 00000000000..e58eae71a62 --- /dev/null +++ b/queue-4.9/9p-trans_fd-abort-p9_read_work-if-req-status-changed.patch @@ -0,0 +1,66 @@ +From 03db58a298f27fe2faa066acaa2cca4eaadef39a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 9 Oct 2018 11:18:52 +0900 +Subject: 9p/trans_fd: abort p9_read_work if req status changed + +From: Dominique Martinet + +[ Upstream commit e4ca13f7d075e551dc158df6af18fb412a1dba0a ] + +p9_read_work would try to handle an errored req even if it got put to +error state by another thread between the lookup (that worked) and the +time it had been fully read. +The request itself is safe to use because we hold a ref to it from the +lookup (for m->rreq, so it was safe to read into the request data buffer +until this point), but the req_list has been deleted at the same time +status changed, and client_cb already has been called as well, so we +should not do either. + +Link: http://lkml.kernel.org/r/1539057956-23741-1-git-send-email-asmadeus@codewreck.org +Signed-off-by: Dominique Martinet +Reported-by: syzbot+2222c34dc40b515f30dc@syzkaller.appspotmail.com +Cc: Eric Van Hensbergen +Cc: Latchesar Ionkov +Signed-off-by: Sasha Levin +--- + net/9p/trans_fd.c | 17 +++++++++++------ + 1 file changed, 11 insertions(+), 6 deletions(-) + +diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c +index aa4586672cee9..91f71958c2e16 100644 +--- a/net/9p/trans_fd.c ++++ b/net/9p/trans_fd.c +@@ -295,7 +295,6 @@ static void p9_read_work(struct work_struct *work) + { + int n, err; + struct p9_conn *m; +- int status = REQ_STATUS_ERROR; + + m = container_of(work, struct p9_conn, rq); + +@@ -375,11 +374,17 @@ static void p9_read_work(struct work_struct *work) + if ((m->req) && (m->rc.offset == m->rc.capacity)) { + p9_debug(P9_DEBUG_TRANS, "got new packet\n"); + spin_lock(&m->client->lock); +- if (m->req->status != REQ_STATUS_ERROR) +- status = REQ_STATUS_RCVD; +- list_del(&m->req->req_list); +- /* update req->status while holding client->lock */ +- p9_client_cb(m->client, m->req, status); ++ if (m->req->status == REQ_STATUS_SENT) { ++ list_del(&m->req->req_list); ++ p9_client_cb(m->client, m->req, REQ_STATUS_RCVD); ++ } else { ++ spin_unlock(&m->client->lock); ++ p9_debug(P9_DEBUG_ERROR, ++ "Request tag %d errored out while we were reading the reply\n", ++ m->rc.tag); ++ err = -EIO; ++ goto error; ++ } + spin_unlock(&m->client->lock); + m->rc.sdata = NULL; + m->rc.offset = 0; +-- +2.25.1 + diff --git a/queue-4.9/9p-trans_fd-fix-concurrency-del-of-req_list-in-p9_fd.patch b/queue-4.9/9p-trans_fd-fix-concurrency-del-of-req_list-in-p9_fd.patch new file mode 100644 index 00000000000..589659e081c --- /dev/null +++ b/queue-4.9/9p-trans_fd-fix-concurrency-del-of-req_list-in-p9_fd.patch @@ -0,0 +1,69 @@ +From ad7271c204ad2ba4eb68de297713b2788e53a948 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 12 Jun 2020 17:08:33 +0800 +Subject: 9p/trans_fd: Fix concurrency del of req_list in + p9_fd_cancelled/p9_read_work + +From: Wang Hai + +[ Upstream commit 74d6a5d5662975aed7f25952f62efbb6f6dadd29 ] + +p9_read_work and p9_fd_cancelled may be called concurrently. +In some cases, req->req_list may be deleted by both p9_read_work +and p9_fd_cancelled. + +We can fix it by ignoring replies associated with a cancelled +request and ignoring cancelled request if message has been received +before lock. + +Link: http://lkml.kernel.org/r/20200612090833.36149-1-wanghai38@huawei.com +Fixes: 60ff779c4abb ("9p: client: remove unused code and any reference to "cancelled" function") +Cc: # v3.12+ +Reported-by: syzbot+77a25acfa0382e06ab23@syzkaller.appspotmail.com +Signed-off-by: Wang Hai +Signed-off-by: Dominique Martinet +Signed-off-by: Sasha Levin +--- + net/9p/trans_fd.c | 15 ++++++++++++++- + 1 file changed, 14 insertions(+), 1 deletion(-) + +diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c +index 91f71958c2e16..b0f47563f0bf3 100644 +--- a/net/9p/trans_fd.c ++++ b/net/9p/trans_fd.c +@@ -377,6 +377,10 @@ static void p9_read_work(struct work_struct *work) + if (m->req->status == REQ_STATUS_SENT) { + list_del(&m->req->req_list); + p9_client_cb(m->client, m->req, REQ_STATUS_RCVD); ++ } else if (m->req->status == REQ_STATUS_FLSHD) { ++ /* Ignore replies associated with a cancelled request. */ ++ p9_debug(P9_DEBUG_TRANS, ++ "Ignore replies associated with a cancelled request\n"); + } else { + spin_unlock(&m->client->lock); + p9_debug(P9_DEBUG_ERROR, +@@ -717,11 +721,20 @@ static int p9_fd_cancelled(struct p9_client *client, struct p9_req_t *req) + { + p9_debug(P9_DEBUG_TRANS, "client %p req %p\n", client, req); + ++ spin_lock(&client->lock); ++ /* Ignore cancelled request if message has been received ++ * before lock. ++ */ ++ if (req->status == REQ_STATUS_RCVD) { ++ spin_unlock(&client->lock); ++ return 0; ++ } ++ + /* we haven't received a response for oldreq, + * remove it from the list. + */ +- spin_lock(&client->lock); + list_del(&req->req_list); ++ req->status = REQ_STATUS_FLSHD; + spin_unlock(&client->lock); + + return 0; +-- +2.25.1 + diff --git a/queue-4.9/fbdev-detect-integer-underflow-at-struct-fbcon_ops-c.patch b/queue-4.9/fbdev-detect-integer-underflow-at-struct-fbcon_ops-c.patch new file mode 100644 index 00000000000..48b85d8946d --- /dev/null +++ b/queue-4.9/fbdev-detect-integer-underflow-at-struct-fbcon_ops-c.patch @@ -0,0 +1,157 @@ +From f9945337eeec58910c91e9fd3cb31b57b8c4755f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 15 Jul 2020 10:51:02 +0900 +Subject: fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins. + +From: Tetsuo Handa + +[ Upstream commit 033724d6864245a11f8e04c066002e6ad22b3fd0 ] + +syzbot is reporting general protection fault in bitfill_aligned() [1] +caused by integer underflow in bit_clear_margins(). The cause of this +problem is when and how do_vc_resize() updates vc->vc_{cols,rows}. + +If vc_do_resize() fails (e.g. kzalloc() fails) when var.xres or var.yres +is going to shrink, vc->vc_{cols,rows} will not be updated. This allows +bit_clear_margins() to see info->var.xres < (vc->vc_cols * cw) or +info->var.yres < (vc->vc_rows * ch). Unexpectedly large rw or bh will +try to overrun the __iomem region and causes general protection fault. + +Also, vc_resize(vc, 0, 0) does not set vc->vc_{cols,rows} = 0 due to + + new_cols = (cols ? cols : vc->vc_cols); + new_rows = (lines ? lines : vc->vc_rows); + +exception. Since cols and lines are calculated as + + cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres); + rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres); + cols /= vc->vc_font.width; + rows /= vc->vc_font.height; + vc_resize(vc, cols, rows); + +in fbcon_modechanged(), var.xres < vc->vc_font.width makes cols = 0 +and var.yres < vc->vc_font.height makes rows = 0. This means that + + const int fd = open("/dev/fb0", O_ACCMODE); + struct fb_var_screeninfo var = { }; + ioctl(fd, FBIOGET_VSCREENINFO, &var); + var.xres = var.yres = 1; + ioctl(fd, FBIOPUT_VSCREENINFO, &var); + +easily reproduces integer underflow bug explained above. + +Of course, callers of vc_resize() are not handling vc_do_resize() failure +is bad. But we can't avoid vc_resize(vc, 0, 0) which returns 0. Therefore, +as a band-aid workaround, this patch checks integer underflow in +"struct fbcon_ops"->clear_margins call, assuming that +vc->vc_cols * vc->vc_font.width and vc->vc_rows * vc->vc_font.heigh do not +cause integer overflow. + +[1] https://syzkaller.appspot.com/bug?id=a565882df74fa76f10d3a6fec4be31098dbb37c6 + +Reported-and-tested-by: syzbot +Signed-off-by: Tetsuo Handa +Acked-by: Daniel Vetter +Cc: stable +Link: https://lore.kernel.org/r/20200715015102.3814-1-penguin-kernel@I-love.SAKURA.ne.jp +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/video/console/bitblit.c | 4 ++-- + drivers/video/console/fbcon_ccw.c | 4 ++-- + drivers/video/console/fbcon_cw.c | 4 ++-- + drivers/video/console/fbcon_ud.c | 4 ++-- + 4 files changed, 8 insertions(+), 8 deletions(-) + +diff --git a/drivers/video/console/bitblit.c b/drivers/video/console/bitblit.c +index dbfe4eecf12e5..05d1d36a56654 100644 +--- a/drivers/video/console/bitblit.c ++++ b/drivers/video/console/bitblit.c +@@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc, struct fb_info *info, + region.color = 0; + region.rop = ROP_COPY; + +- if (rw && !bottom_only) { ++ if ((int) rw > 0 && !bottom_only) { + region.dx = info->var.xoffset + rs; + region.dy = 0; + region.width = rw; +@@ -224,7 +224,7 @@ static void bit_clear_margins(struct vc_data *vc, struct fb_info *info, + info->fbops->fb_fillrect(info, ®ion); + } + +- if (bh) { ++ if ((int) bh > 0) { + region.dx = info->var.xoffset; + region.dy = info->var.yoffset + bs; + region.width = rs; +diff --git a/drivers/video/console/fbcon_ccw.c b/drivers/video/console/fbcon_ccw.c +index 5a3cbf6dff4d9..34da8bba9273a 100644 +--- a/drivers/video/console/fbcon_ccw.c ++++ b/drivers/video/console/fbcon_ccw.c +@@ -201,7 +201,7 @@ static void ccw_clear_margins(struct vc_data *vc, struct fb_info *info, + region.color = 0; + region.rop = ROP_COPY; + +- if (rw && !bottom_only) { ++ if ((int) rw > 0 && !bottom_only) { + region.dx = 0; + region.dy = info->var.yoffset; + region.height = rw; +@@ -209,7 +209,7 @@ static void ccw_clear_margins(struct vc_data *vc, struct fb_info *info, + info->fbops->fb_fillrect(info, ®ion); + } + +- if (bh) { ++ if ((int) bh > 0) { + region.dx = info->var.xoffset + bs; + region.dy = 0; + region.height = info->var.yres_virtual; +diff --git a/drivers/video/console/fbcon_cw.c b/drivers/video/console/fbcon_cw.c +index e7ee44db4e98b..0b552b3fc22ab 100644 +--- a/drivers/video/console/fbcon_cw.c ++++ b/drivers/video/console/fbcon_cw.c +@@ -184,7 +184,7 @@ static void cw_clear_margins(struct vc_data *vc, struct fb_info *info, + region.color = 0; + region.rop = ROP_COPY; + +- if (rw && !bottom_only) { ++ if ((int) rw > 0 && !bottom_only) { + region.dx = 0; + region.dy = info->var.yoffset + rs; + region.height = rw; +@@ -192,7 +192,7 @@ static void cw_clear_margins(struct vc_data *vc, struct fb_info *info, + info->fbops->fb_fillrect(info, ®ion); + } + +- if (bh) { ++ if ((int) bh > 0) { + region.dx = info->var.xoffset; + region.dy = info->var.yoffset; + region.height = info->var.yres; +diff --git a/drivers/video/console/fbcon_ud.c b/drivers/video/console/fbcon_ud.c +index 19e3714abfe8f..7f62efe2da526 100644 +--- a/drivers/video/console/fbcon_ud.c ++++ b/drivers/video/console/fbcon_ud.c +@@ -231,7 +231,7 @@ static void ud_clear_margins(struct vc_data *vc, struct fb_info *info, + region.color = 0; + region.rop = ROP_COPY; + +- if (rw && !bottom_only) { ++ if ((int) rw > 0 && !bottom_only) { + region.dy = 0; + region.dx = info->var.xoffset; + region.width = rw; +@@ -239,7 +239,7 @@ static void ud_clear_margins(struct vc_data *vc, struct fb_info *info, + info->fbops->fb_fillrect(info, ®ion); + } + +- if (bh) { ++ if ((int) bh > 0) { + region.dy = info->var.yoffset; + region.dx = info->var.xoffset; + region.height = bh; +-- +2.25.1 + diff --git a/queue-4.9/series b/queue-4.9/series index 900eafd252e..9626517f767 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -15,3 +15,8 @@ drm-amdgpu-prevent-kernel-infoleak-in-amdgpu_info_ioctl.patch drm-hold-gem-reference-until-object-is-no-longer-accessed.patch f2fs-check-memory-boundary-by-insane-namelen.patch f2fs-check-if-file-namelen-exceeds-max-value.patch +9p-trans_fd-abort-p9_read_work-if-req-status-changed.patch +9p-trans_fd-fix-concurrency-del-of-req_list-in-p9_fd.patch +x86-build-lto-fix-truncated-.bss-with-fdata-sections.patch +x86-vmlinux.lds-page-align-end-of-.page_aligned-sect.patch +fbdev-detect-integer-underflow-at-struct-fbcon_ops-c.patch diff --git a/queue-4.9/x86-build-lto-fix-truncated-.bss-with-fdata-sections.patch b/queue-4.9/x86-build-lto-fix-truncated-.bss-with-fdata-sections.patch new file mode 100644 index 00000000000..4b38748669c --- /dev/null +++ b/queue-4.9/x86-build-lto-fix-truncated-.bss-with-fdata-sections.patch @@ -0,0 +1,54 @@ +From 80302c3b19488e0153d42224bd388b2e341dac86 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 15 Apr 2019 09:49:56 -0700 +Subject: x86/build/lto: Fix truncated .bss with -fdata-sections + +From: Sami Tolvanen + +[ Upstream commit 6a03469a1edc94da52b65478f1e00837add869a3 ] + +With CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y, we compile the kernel with +-fdata-sections, which also splits the .bss section. + +The new section, with a new .bss.* name, which pattern gets missed by the +main x86 linker script which only expects the '.bss' name. This results +in the discarding of the second part and a too small, truncated .bss +section and an unhappy, non-working kernel. + +Use the common BSS_MAIN macro in the linker script to properly capture +and merge all the generated BSS sections. + +Signed-off-by: Sami Tolvanen +Reviewed-by: Nick Desaulniers +Reviewed-by: Kees Cook +Cc: Borislav Petkov +Cc: Kees Cook +Cc: Linus Torvalds +Cc: Nicholas Piggin +Cc: Nick Desaulniers +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Link: http://lkml.kernel.org/r/20190415164956.124067-1-samitolvanen@google.com +[ Extended the changelog. ] +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/vmlinux.lds.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S +index 097268f85e4ee..0df44e4fe7cb1 100644 +--- a/arch/x86/kernel/vmlinux.lds.S ++++ b/arch/x86/kernel/vmlinux.lds.S +@@ -329,7 +329,7 @@ SECTIONS + .bss : AT(ADDR(.bss) - LOAD_OFFSET) { + __bss_start = .; + *(.bss..page_aligned) +- *(.bss) ++ *(BSS_MAIN) + . = ALIGN(PAGE_SIZE); + __bss_stop = .; + } +-- +2.25.1 + diff --git a/queue-4.9/x86-vmlinux.lds-page-align-end-of-.page_aligned-sect.patch b/queue-4.9/x86-vmlinux.lds-page-align-end-of-.page_aligned-sect.patch new file mode 100644 index 00000000000..02f1b7c6d12 --- /dev/null +++ b/queue-4.9/x86-vmlinux.lds-page-align-end-of-.page_aligned-sect.patch @@ -0,0 +1,84 @@ +From 952f6a132d427c253e7d697e70ed68277b811a1f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 21 Jul 2020 11:34:48 +0200 +Subject: x86, vmlinux.lds: Page-align end of ..page_aligned sections + +From: Joerg Roedel + +[ Upstream commit de2b41be8fcccb2f5b6c480d35df590476344201 ] + +On x86-32 the idt_table with 256 entries needs only 2048 bytes. It is +page-aligned, but the end of the .bss..page_aligned section is not +guaranteed to be page-aligned. + +As a result, objects from other .bss sections may end up on the same 4k +page as the idt_table, and will accidentially get mapped read-only during +boot, causing unexpected page-faults when the kernel writes to them. + +This could be worked around by making the objects in the page aligned +sections page sized, but that's wrong. + +Explicit sections which store only page aligned objects have an implicit +guarantee that the object is alone in the page in which it is placed. That +works for all objects except the last one. That's inconsistent. + +Enforcing page sized objects for these sections would wreckage memory +sanitizers, because the object becomes artificially larger than it should +be and out of bound access becomes legit. + +Align the end of the .bss..page_aligned and .data..page_aligned section on +page-size so all objects places in these sections are guaranteed to have +their own page. + +[ tglx: Amended changelog ] + +Signed-off-by: Joerg Roedel +Signed-off-by: Thomas Gleixner +Reviewed-by: Kees Cook +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20200721093448.10417-1-joro@8bytes.org +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/vmlinux.lds.S | 1 + + include/asm-generic/vmlinux.lds.h | 5 ++++- + 2 files changed, 5 insertions(+), 1 deletion(-) + +diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S +index 0df44e4fe7cb1..a1082dc61bb96 100644 +--- a/arch/x86/kernel/vmlinux.lds.S ++++ b/arch/x86/kernel/vmlinux.lds.S +@@ -329,6 +329,7 @@ SECTIONS + .bss : AT(ADDR(.bss) - LOAD_OFFSET) { + __bss_start = .; + *(.bss..page_aligned) ++ . = ALIGN(PAGE_SIZE); + *(BSS_MAIN) + . = ALIGN(PAGE_SIZE); + __bss_stop = .; +diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h +index 1462071a19bf2..4fdb1d9848444 100644 +--- a/include/asm-generic/vmlinux.lds.h ++++ b/include/asm-generic/vmlinux.lds.h +@@ -250,7 +250,8 @@ + + #define PAGE_ALIGNED_DATA(page_align) \ + . = ALIGN(page_align); \ +- *(.data..page_aligned) ++ *(.data..page_aligned) \ ++ . = ALIGN(page_align); + + #define READ_MOSTLY_DATA(align) \ + . = ALIGN(align); \ +@@ -625,7 +626,9 @@ + . = ALIGN(bss_align); \ + .bss : AT(ADDR(.bss) - LOAD_OFFSET) { \ + BSS_FIRST_SECTIONS \ ++ . = ALIGN(PAGE_SIZE); \ + *(.bss..page_aligned) \ ++ . = ALIGN(PAGE_SIZE); \ + *(.dynbss) \ + *(BSS_MAIN) \ + *(COMMON) \ +-- +2.25.1 + -- 2.47.3