linux-kernel - Re: [2.6.27.24] Kernel coredump to a pipe is failing

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:	Wed, 27 May 2009 16:22:49 -0400
From:	Paul Smith <paul@...-scientist.net>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>
Subject: Re: [2.6.27.24] Kernel coredump to a pipe is failing

On Wed, 2009-05-27 at 22:04 +0200, Oleg Nesterov wrote:
> Forgot to mention, and we have problems with OOM. Not only the coredumping
> task can't be killed (and it can populate the memory via get_user_pages).
> The coredump just disables OOM, if select_bad_process() sees the PF_EXITING
> task with ->mm == NULL it returns -1.
> 
> > This all needs more discussion, but imho for now something like
> > Paul's patch http://marc.info/?l=linux-kernel&m=124340506200729
> > is the best workaround. Note that we have the same dump_write()
> > in binfmt_elf.c and binfmt_aout.c, perhaps it makes sense to
> > create coredump_file_write() helper in fs/exec.c.
> 
> But I didn't notice Paul also reports the kernel panic:
> 
> 	page:ffffe20010d63d00 flags:0x8000000000000001 mapping:0000000000000000 mapcount:0 \
> 	count:0 Trying to fix it up, but a reboot is needed
> 	Backtrace:
> 	Pid: 3346, comm: worker Tainted: P          2.6.27.24-worker #4
> 
> 	Call Trace:
> 	 [<ffffffff80284fd4>] bad_page+0x74/0xc0
> 	 [<ffffffff80286168>] free_hot_cold_page+0x248/0x2f0
> 	 [<ffffffff802f4096>] free_wr_note_data+0x56/0x70
> 	 [<ffffffff802a95c6>] kfree+0x86/0x100
> 	 [<ffffffff802f4096>] free_wr_note_data+0x56/0x70
> 	 [<ffffffff802f0991>] elf_core_dump+0x611/0x1160
> 
> At first glance, this looks like a bug outside of coredump.c,
> we are trying to free PG_locked page?

This might be something different, or a side-effect that's not
understood; I haven't seen this happen again since I applied my change,
and I used to be able to make it happen every time within 2 or 3
invocations of my "failing" core dump procedure.  Now I have dumped core
using my "failing" procedure 10-15 times in a row with no ill-effects.

I'll keep an eye out for this one though.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/