linux-kernel - Re: [PATCH] scatterlist: don't overflow length field

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: <CA+55aFwksH6sry-QBwt8_g8di938UxLJfotob3LY5XS8xhSBag@mail.gmail.com>
Date:   Fri, 3 Feb 2017 11:57:10 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Dillow <dillow@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] scatterlist: don't overflow length field

On Wed, Feb 1, 2017 at 1:29 PM, David Dillow <dillow@...gle.com> wrote:
> When called with a region of contiguous pages totaling > 4 GB of memory,
> sg_alloc_table_from_pages() will overflow the length field, leading to a
> corrupt scatter list. Fix this by tracking the number of pages we've
> merged and start a new chunk when we would overflow.

So what allows these things to be built in the first place?

We limit IO sizes to fit in a signed int (so just below 2GB) not only
because it's often an effective denial of service, but also because
we've had issues with various drivers (and filesystems) getting
int/long wrong.

So nothing should be building those kinds of scatterlists, and it
something is able to, it might result in other problems downstreams..

Put another way: why not just say "this can't happen", and make the
sg_alloc_table_from_pages() perhaps also have the same check.

MAX_RW_COUNT is what we limit reads and writes to:

    #define MAX_RW_COUNT (INT_MAX & PAGE_MASK)

Hmm?

                   Linus