Bug 25888 - [regression] umount.hal aborts with fortify
[regression] umount.hal aborts with fortify
Status: RESOLVED FIXED
Product: hal
Classification: Unclassified
Component: misc
unspecified
Other All
: medium major
Assigned To: Martin Pitt
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-04 06:38 UTC by Peter
Modified: 2010-01-04 08:00 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter 2010-01-04 06:38:13 UTC
After adding support for relative paths in umount.hal[1] it aborts if built with _FORTIFY_SOURCE=2: 

 # umount.hal /boot/
*** buffer overflow detected ***: umount.hal terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x7f346e5127b7]
/lib/libc.so.6(+0xe2640)[0x7f346e510640]
/lib/libc.so.6(+0xe2cab)[0x7f346e510cab]
umount.hal(main+0xaa)[0x400e6a]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f346e44cbbd]
umount.hal[0x400cf9]
======= Memory map: ========
[snip]

Fortify source is default since gcc-4.3 and thus default build is affected. Problem is that glibc explicitly requires that second argument to realpath(), device_file_or_mount_point in this case, must be larger then PATH_MAX (see info libc: On systems which define `PATH_MAX' ... the buffer must be large enough for a pathname of this size.). Since HAL_PATH_MAX=1024 is smaller then PATH_MAX=4096 this causes this abort.

[1] http://cgit.freedesktop.org/hal/commit/?id=6d8eed9015a6ca648fe1dad575621b6ea959a748
Comment 1 Martin Pitt 2010-01-04 07:57:30 UTC
I checked the code, and there's indeed a second place which uses realpath() with HAL_PATH_MAX.