On Tue, Jun 27, 2017 at 7:49 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Wed 21-06-17 10:32:01, Kees Cook wrote: >> The ELF_ET_DYN_BASE position was originally intended to keep loaders >> away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2 >> /bin/cat" might cause the subsequent load of /bin/cat into where the >> loader had been loaded.) With the advent of PIE (ET_DYN binaries with >> an INTERP Program Header), ELF_ET_DYN_BASE continued to be used since >> the kernel was only looking at ET_DYN. However, since ELF_ET_DYN_BASE >> is traditionally set at the top 1/3rd of the TASK_SIZE, a substantial >> portion of the address space is unused. >> >> For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs >> are loaded below the mmap region. This means they can be made to collide >> (CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with pathological >> stack regions. Lowering ELF_ET_DYN_BASE solves both by moving programs >> above the mmap region in all cases, and will now additionally avoid >> programs falling back to the mmap region by enforcing MAP_FIXED for >> program loads (i.e. if it would have collided with the stack, now it >> will fail to load instead of falling back to the mmap region). > > I do not understand this part. MAP_FIXED will simply unmap whatever > was under the requested range, how it could help failing anything? So > what would happen if something was mapped in that region, or is this > impossible? Moreover MAP_FIXED close to stack will inhibit the stack gap > protection. Hmm, well, that's my misunderstanding. Regardless, it should still use MAP_FIXED otherwise we end up with potentially unpredictable results. (Note that MAP_FIXED is already used all all remaining allocations, it was just missing on the first one.) -Kees -- Kees Cook Pixel Security
