Hi Didier,

On 1/30/26 16:48, Didier Kryn wrote:
> I'm not sure about calling blkid_put_cache(). It's fine when you have
> no priviledge, but I'm afaid it could be dangerous from a priviledged
> program -- though the priviledges are going to be reduced. And what is
> it needed for? the program is a one-shot, not a long-lasting server.

|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.|||