linux-kernel - 4.1.28: memory leak introduced by "mm/swap.c: flush lru pvecs on compound page arrival"

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-next>] [day] [month] [year] [list]

Date:	Fri, 15 Jul 2016 21:27:55 +0200
From:	Jens Rottmann <Jens.Rottmann@...INKtech.com>
To:	Lukasz Odzioba <lukasz.odzioba@...el.com>,
	Sasha Levin <sasha.levin@...cle.com>
CC:	<stable@...r.kernel.org>, Michal Hocko <mhocko@...e.com>,
	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>
Subject: 4.1.28: memory leak introduced by "mm/swap.c: flush lru pvecs on
 compound page arrival"

Hi,

4.1.y stable commit c5ad33184354260be6d05de57e46a5498692f6d6 (Upstream
commit 8f182270dfec432e93fae14f9208a6b9af01009f) "mm/swap.c: flush lru
pvecs on compound page arrival" in 4.1.28 introduces a memory leak.

Simply running

while sleep 0.1; do clear; free; done

shows mem continuously going down, eventually system panics with no
killable processes left. Using "unxz -t some.xz" instead of sleep brings
system down within minutes.

Kmemleak did not report anything. Bisect ended at named commit, and
reverting only this commit is indeed sufficient to fix the leak. Swap
partition on/off makes no difference.

My set-up:
i.MX6 (ARM Cortex-A9) dual-core, 2 GB RAM. Kernel sources are from
git.freescale.com i.e. heavily modified by Freescale for i.MX SoCs,
kernel.org stable patches up to 4.1.28 manually added.

I tried to reproduce with vanilla 4.1.28, but that wouldn't boot at all
on my hardware, hangs immediately after "Starting kernel", sorry.
However there is not a single difference between Freescale and vanilla
in the whole mm/ subdirectory, so I don't think it's i.MX-specific. I
didn't cross-check with an x86 system (yet).

Regards,
Jens