--- /dev/null
+From 03db58a298f27fe2faa066acaa2cca4eaadef39a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 9 Oct 2018 11:18:52 +0900
+Subject: 9p/trans_fd: abort p9_read_work if req status changed
+
+From: Dominique Martinet <dominique.martinet@cea.fr>
+
+[ 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 <dominique.martinet@cea.fr>
+Reported-by: syzbot+2222c34dc40b515f30dc@syzkaller.appspotmail.com
+Cc: Eric Van Hensbergen <ericvh@gmail.com>
+Cc: Latchesar Ionkov <lucho@ionkov.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From ad7271c204ad2ba4eb68de297713b2788e53a948 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <wanghai38@huawei.com>
+
+[ 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: <stable@vger.kernel.org> # v3.12+
+Reported-by: syzbot+77a25acfa0382e06ab23@syzkaller.appspotmail.com
+Signed-off-by: Wang Hai <wanghai38@huawei.com>
+Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From f9945337eeec58910c91e9fd3cb31b57b8c4755f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Jul 2020 10:51:02 +0900
+Subject: fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+[ 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 <syzbot+e5fd3e65515b48c02a30@syzkaller.appspotmail.com>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200715015102.3814-1-penguin-kernel@I-love.SAKURA.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
--- /dev/null
+From 80302c3b19488e0153d42224bd388b2e341dac86 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 15 Apr 2019 09:49:56 -0700
+Subject: x86/build/lto: Fix truncated .bss with -fdata-sections
+
+From: Sami Tolvanen <samitolvanen@google.com>
+
+[ 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 <samitolvanen@google.com>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Nicholas Piggin <npiggin@gmail.com>
+Cc: Nick Desaulniers <ndesaulniers@google.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/20190415164956.124067-1-samitolvanen@google.com
+[ Extended the changelog. ]
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 952f6a132d427c253e7d697e70ed68277b811a1f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 21 Jul 2020 11:34:48 +0200
+Subject: x86, vmlinux.lds: Page-align end of ..page_aligned sections
+
+From: Joerg Roedel <jroedel@suse.de>
+
+[ 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 <jroedel@suse.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20200721093448.10417-1-joro@8bytes.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
