Bug#980037: libapt tries to access old memory area after mremap(,,MREMAP_MAYMOVE)
On Wed, Jan 13, 2021 at 12:08:39PM +0200, Topi Miettinen wrote:
> Package: libapt-pkg6.0
> Version: 2.1.17
>
> I'm using a patched kernel (upstream 5.10.0 + https://patchwork.kernel.org/project/linux-mm/patch/20201220180656.43843-1-toiwoton@gmail.com/)
> where mremap() always remaps memory to a different address to improve
> address space layout randomization, when remapping is allowed by the caller
> with MREMAP_MAYMOVE flag and sysctl randomize_va_space is set to new value
> of 3. Remapping the memory may happen also with non-patched kernels too but
> it's much rarer event.
>
> This seems to expose a bug in apt:
>
> $ strace apt search apt
> read(6, "led-Size: 289\nMaintainer: Debian"..., 32682) = 32682
> read(6, " 30d94c7e581c7b46aa62d229ee7654f"..., 32116) = 32116
> mremap(0x7e59a35ac000, 33554432, 34603008, MREMAP_MAYMOVE) = 0x5c24c86c3000
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7e59a5593e80}
> ---
> +++ killed by SIGSEGV (core dumped) +++
> Segmentation fault (core dumped)
>
> The address 0x7e59a5593e80 refers to old memory area, which may not be
> accessed after remapping.
>
> $ gdb apt
> (gdb) r search apt
> Starting program: /usr/bin/apt search apt
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [Detaching after fork from child process 27645]
> [Detaching after fork from child process 27646]
> [Detaching after fork from child process 27647]
> [Detaching after fork from child process 27648]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007090d7a60f1c in pkgCacheGenerator::NewVersion
> (this=this@entry=0x26c5ff9fc990, Ver=..., VerStr=..., ParentPkg=...,
> Hash=Hash@entry=1269831082, Next=...) at ../apt-pkg/pkgcachegen.cc:876
> warning: Source file is more recent than executable.
> 876 Ver->d = AllocateInMap<pkgCache::Version::Extra>();
I think it's missing a sequence point here? After AllocateInMap returns,
Ver will have been readjusted (it's wrapped in a dynamic<> helper in the
caller), but I think the left hand side might be evaluated first here,
so fix would be
auto d = AllocateInMap<pkgCache::Version::Extra>();
Ver->d = d;
If you can test that'd be appreciated :)
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: