linux-kernel - Re: [PATCH][CFT] [coredump] don't use __kernel_write() on kmap_local

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 3 Oct 2022 23:18:37 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Ira Weiny <ira.weiny@...el.com>
Cc:     "J. R. Okajima" <hooanon05g@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH][CFT] [coredump] don't use __kernel_write() on
 kmap_local_page()

On Mon, Oct 03, 2022 at 12:31:36PM -0700, Ira Weiny wrote:
> On Mon, Oct 03, 2022 at 07:48:28PM +0900, J. R. Okajima wrote:
> > Ira Weiny:
> > > On Wed, Sep 28, 2022 at 07:29:43PM +0100, Al Viro wrote:
> > > > On Tue, Sep 27, 2022 at 11:51:17PM +0100, Al Viro wrote:
> > > > > [I'm going to send a pull request tomorrow if nobody yells;
> > > > > please review and test - it seems to work fine here, but extra
> > > > > eyes and extra testing would be very welcome]
> > 
> > I tried gdb backtrace 'bt' command with the new core by v6.0, and it
> > doesn't show the call trace correctly. Is it related to this commit?
> >
> 
> Are you also getting something like this?
> 
> BFD: warning: /mnt/9p/test-okajima/core is truncated: expected core file size >= 225280, found: 76616
> 
> I did not see that before.  I'm running through this patch vs a fix to
> kmap_to_page()[1] and I may have gotten the 2 crossed up.  So I'm retesting
> with your test below.

Argh....  Try this:

fix coredump breakage caused by badly tested "[coredump] don't use __kernel_write() on kmap_local_page()"

Let me count the ways I'd screwed up:

* when emitting a page, handling of gaps in coredump should happen
before fetching the current file position.
* fix for problem that occurs on rather uncommon setups (and hadn't
been observed in the wild) sent very late in the cycle.
* ... with badly insufficient testing, introducing an easily
reproducable breakage.  Without giving it time to soak in -next.

Fucked-up-by: Al Viro <viro@...iv.linux.org.uk>
Fixes: 06bbaa6dc53c "[coredump] don't use __kernel_write() on kmap_local_page()"
Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
---
diff --git a/fs/coredump.c b/fs/coredump.c
index 1ab4f5b76a1e..3538f3a63965 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -841,7 +841,7 @@ static int dump_emit_page(struct coredump_params *cprm, struct page *page)
 	};
 	struct iov_iter iter;
 	struct file *file = cprm->file;
-	loff_t pos = file->f_pos;
+	loff_t pos;
 	ssize_t n;
 
 	if (cprm->to_skip) {
@@ -853,6 +853,7 @@ static int dump_emit_page(struct coredump_params *cprm, struct page *page)
 		return 0;
 	if (dump_interrupted())
 		return 0;
+	pos = file->f_pos;
 	iov_iter_bvec(&iter, WRITE, &bvec, 1, PAGE_SIZE);
 	n = __kernel_write_iter(cprm->file, &iter, &pos);
 	if (n != PAGE_SIZE)