On Tue, Dec 20, 2016 at 8:21 PM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx> writes:
>> OK -- if userspace messes up again it may be a bit hard to prove
>> unless we have a validation debug thing in place, would such a thing
>> in debug form be reasonable ?
>
> That makes perfect sense. Untested hack:
>
> diff --git a/fs/filesystems.c b/fs/filesystems.c
> index c5618db110be..e5c90e80c7d3 100644
> --- a/fs/filesystems.c
> +++ b/fs/filesystems.c
> @@ -275,9 +275,10 @@ struct file_system_type *get_fs_type(const char *name)
> int len = dot ? dot - name : strlen(name);
>
> fs = __get_fs_type(name, len);
> - if (!fs && (request_module("fs-%.*s", len, name) == 0))
> + if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
> fs = __get_fs_type(name, len);
> -
> + WARN_ONCE(!fs, "request_module fs-%.*s succeeded, but still no fs?\n", len, name);
> + }
> if (dot && fs && !(fs->fs_flags & FS_HAS_SUBTYPE)) {
> put_filesystem(fs);
> fs = NULL;
This is precisely a type of debug patch we had added first to verify "WTF".
> Maybe a similar hack for try_then_request_module(), but many places seem
> to open-code request_module() so it's not as trivial...
Right, out of ~350 request_module() calls (not included try requests)
only ~46 check the return value. Hence a validation check, and come to
think of it, *this* was the issue that originally had me believing
that in some places we might end up in a null deref --if those open
coded request_module() calls assume the driver is loaded there could
be many places where a NULL is inevitable. Granted, I agree they
should be fixed, we could add a grammar rule to start nagging at
driver developers for started, but it does beg the question also of
what a tightly knit validation for modprobe might look like, and hence
this patch and now the completed not-yet-posted alias work.
Would it be worthy as a kconfig kmod debugging aide for now? I can
follow up with a semantic patch to nag about checking the return value
of request_module(), and we can have 0-day then also complain about
new invalid uses.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
