linux-kernel - Re: [PATCH] mm: Fix int overflow in callers of do_shrink

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:   Fri, 28 Sep 2018 14:15:09 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Kirill Tkhai <ktkhai@...tuozzo.com>
Cc:     gorcunov@...nvz.org, mhocko@...e.com, aryabinin@...tuozzo.com,
        hannes@...xchg.org, penguin-kernel@...ove.SAKURA.ne.jp,
        shakeelb@...gle.com, jbacik@...com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: Fix int overflow in callers of do_shrink_slab()

On Fri, 28 Sep 2018 14:28:32 +0300 Kirill Tkhai <ktkhai@...tuozzo.com> wrote:

> do_shrink_slab() returns unsigned long value, and
> the placing into int variable cuts high bytes off.
> Then we compare ret and 0xfffffffe (since SHRINK_EMPTY
> is converted to ret type).
> 
> Thus, big number of objects returned by do_shrink_slab()
> may be interpreted as SHRINK_EMPTY, if low bytes of
> their value are equal to 0xfffffffe. Fix that
> by declaration ret as unsigned long in these functions.

Sigh.  How many times has this happened.

> Reported-by: Cyrill Gorcunov <gorcunov@...nvz.org>

What did he report?  Was it code inspection?  Did the kernel explode? 
etcetera.  I'm thinking that the fix should be backported but to
determine that, we need to understand the end-user runtime effects, as
always.  Please.