Hi, I found a bug in the hash implementation that is part of libkmod. As a result depmod fails to deal with modules if they are the *target* of a symlink. (The symlink must be also part of the directory hierarchy that depmod parses.) I.e. the following scenario causes depmod to not handle symbols of module rtai_sched.ko: $ cd /lib/modules/$(uname -r)/rtai $ ls -l rtai_*sched.ko lrwxrwxrwx 1 root root 13 Apr 30 12:12 rtai_ksched.ko -> rtai_sched.ko -rw-r--r-- 1 root root 100925 Apr 30 12:12 rtai_sched.ko The following patch fixes that problem: >From 4363adddbdd0ac121f9a8ce0082b0f7fa132a1b0 Mon Sep 17 00:00:00 2001 From: Lukas Anzinger <lukas@xxxxxxxxxxxxxxxx> Date: Sun, 18 May 2014 18:40:19 +0200 Subject: [PATCH] Fix use-after-free in hash implementation. If a value is added to the hash under a key that already exists the new value replaces the old value for that key. Since key can be a pointer to data that is part of value and freed by hash->free_value(), the key must be also replaced and not only the value. Otherwise key potentially points to freed data. --- libkmod/libkmod-hash.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libkmod/libkmod-hash.c b/libkmod/libkmod-hash.c index c751d2d..eb7afb7 100644 --- a/libkmod/libkmod-hash.c +++ b/libkmod/libkmod-hash.c @@ -169,6 +169,7 @@ int hash_add(struct hash *hash, const char *key, const void *value) if (c == 0) { if (hash->free_value) hash->free_value((void *)entry->value); + entry->key = key; entry->value = value; return 0; } else if (c < 0) { -- 1.9.1 I've also written a blog post that describes the problem in great detail. If you're interested how I found that bug you might want to read this article: https://www.notinventedhere.org/articles/linux/why-implementing-your-own-data-structures-in-c-is-a-bad-idea.html Regards, Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html