Hi again,

On 1/30/26 22:19, aitor wrote:
>
> |In the line 107 of main.c| you use |blkid_get_cache(&cache, 0)|. The
> |"0"| tells the library to use the default cache file (usually
> |/etc/blkid.tab|).
>
> https://www.kernel.org/pub/linux/utils/util-linux/v2.27/libblkid-docs/libblkid-Cache.html#blkid-get-cache
>
>
> In order to by-pass the disk cache and force a fresh scan of the
> hardware you need to modify your blkid initialization:
>
> |if( blkid_get_cache(&cache, 0) ) gotocache_error; with this one: if(
> blkid_get_cache(&cache, "/dev/null") ) gotocache_error;
> blkid_probe_all(cache); // Force a refresh of all devices |
>
> |Even though, the use of blkid_put_cache() is still necessary
> because libblkid uses a ‘Reference Counting’ style naming convention
> to manage the lifecycle of a struct, where every *get* has a *put*, in
> the same way that in Glib's GObject every g_object_ref() has a
> g_object_unref(). The former increments the usage of the object, and
> the latter decrements it releasing the object. When the count reaches
> zero, the object is deallocated. By way of clarification, to take the
> ownership of an object involves taking the responsibility for
> destroying the object.|
>
> |T||he ||blkid||initialization in qmount allocates dynamic memory in
> the heap to manage the blkid_cache structure, even if you have
> configured the cache so that it does not read or write to the disk (by
> forcing fresh hardware probing with "/dev/null"). However, there is no
> blkid_put_cache() as it ought to be according to the *Get/Put*
> convention. While this is not fatal for a short run, if you use qmount
> in a script that processes many disks, the memory leak will grow. As
> for the linux capabilities, if there is a code error or buffer
> overflow before the program terminates, an attacker could exploit that
> vulnerability while the process still has CAP_SYS_ADMIN. It is not
> about what happens when qmount terminates, but rather what could go
> wrong while qmount is still running.|
>
> |Cheers,|
>
> |Aitor.|||

Sorry for the symbols above, I've been changing the font format... Here you are the text replicated:

In the line 107 of main.c, you use blkid_get_cache(&cache, 0). The "0" tells the library to use the default
cache file (usually /etc/blkid.tab).


https://www.kernel.org/pub/linux/utils/util-linux/v2.27/libblkid-docs/libblkid-Cache.html#blkid-get-cache


In order to by-pass the disk cache and force a fresh scan of the hardware you need to modify your blkid
initialization:

if( blkid_get_cache(&cache, 0) ) gotocache_error;

with this one:

if( blkid_get_cache(&cache, "/dev/null") ) gotocache_error;
blkid_probe_all(cache);   // Force a refresh of all devices


Even though, the use of blkid_put_cache() is still necessary because libblkid uses a ‘Reference Counting’ style
naming convention to manage the lifecycle of a struct, where every*get* has a*put*, in the same way that in
Glib's GObject every g_object_ref() has a g_object_unref(). The former increments the usage of the object, and
the latter decrements it releasing the object. When the count reaches zero, the object is deallocated. By way
of clarification, to take the ownership of an object involves taking the responsibility for destroying the object.

The blkid initialization in qmount allocates dynamic memory in the heap to manage the blkid_cache structure,
even if you have configured the cache so that it does not read or write to the disk (by forcing fresh hardware
probing with "/dev/null"). However, there is no blkid_put_cache() as it ought to be according to the*Get/Put*
convention. While this is not fatal for a short run, if you use qmount in a script that processes many disks,
the memory leak will grow.

As for the linux capabilities, if there is a code error or buffer overflow before the program terminates, an
attacker could exploit that vulnerability while the process still has CAP_SYS_ADMIN. It is not about what happens
when qmount terminates, but rather what could go wrong while qmount is still running.

Cheers,

Aitor.