Bug 25888

Summary: [regression] umount.hal aborts with fortify
Product: hal Reporter: Peter <pva>
Component: miscAssignee: Martin Pitt <martin.pitt>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: medium CC: martin.pitt
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.