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]
Message-ID: <20111202204613.GA2297@dhcp-26-164.brq.redhat.com>
Date:	Fri, 2 Dec 2011 21:46:13 +0100
From:	Frantisek Hrbata <fhrbata@...hat.com>
To:	Greg KH <gregkh@...e.de>
Cc:	rientjes@...gle.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	kosaki.motohiro@...fujitsu.com, oleg@...hat.com,
	minchan.kim@...il.com, stable@...nel.org, eteo@...hat.com,
	pmatouse@...hat.com
Subject: Re: [PATCH v2 RESEND] oom: fix integer overflow of points in
 oom_badness

On Fri, Dec 02, 2011 at 11:00:19AM -0800, Greg KH wrote:
> On Fri, Dec 02, 2011 at 06:45:27PM +0100, Frantisek Hrbata wrote:
> > An integer overflow will happen on 64bit archs if task's sum of rss, swapents
> > and nr_ptes exceeds (2^31)/1000 value. This was introduced by commit
> > 
> > f755a04 oom: use pte pages in OOM score
> > 
> > where the oom score computation was divided into several steps and it's no
> > longer computed as one expression in unsigned long(rss, swapents, nr_pte are
> > unsigned long), where the result value assigned to points(int) is in
> > range(1..1000). So there could be an int overflow while computing
> > 
> > 176          points *= 1000;
> > 
> > and points may have negative value. Meaning the oom score for a mem hog task
> > will be one.
> > 
> > 196          if (points <= 0)
> > 197                  return 1;
> > 
> > For example:
> > [ 3366]     0  3366 35390480 24303939   5       0             0 oom01
> > Out of memory: Kill process 3366 (oom01) score 1 or sacrifice child
> > 
> > Here the oom1 process consumes more than 24303939(rss)*4096~=92GB physical
> > memory, but it's oom score is one.
> > 
> > In this situation the mem hog task is skipped and oom killer kills another and
> > most probably innocent task with oom score greater than one.
> > 
> > The points variable should be of type long instead of int to prevent the int
> > overflow.
> > 
> > Signed-off-by: Frantisek Hrbata <fhrbata@...hat.com>
> > Acked-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> > Acked-by: Oleg Nesterov <oleg@...hat.com>
> > Acked-by: David Rientjes <rientjes@...gle.com>
> > Cc: stable@...nel.org [2.6.36+]
> 
> For what it's worth, the stable address has changed to
> stable@...r.kernel.org so you might want to fix that up in future
> submissions.

I was not aware of this change.

> 
> I still catch patches that are tagged with this marking, but you will
> not end up posting stuff to the list this way :)

Duly noted :)

> 
> thanks,

Thanks Greg!

> 
> greg k-h

-- 
Frantisek Hrbata
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ