busybox modprobe reads any file below /etc/modprobe.d/ and interpres that as a
configuration file for modprobe.  The only exception are hidden files
(basename matching ".*").

However, the sysnopsis the modprobe.d(5) manual page (from kmod version 18)
suggests that only the files matching the following globs should be read as
config files:

  /lib/modprobe.d/*.conf
  /etc/modprobe.d/*.conf
  /run/modprobe.d/*.conf

Steps to reproduce
==================

paranoia:/etc# echo @ >modprobe.d/testfile
paranoia:/etc# echo @ >modprobe.d/testfile.conf
paranoia:/etc# modprobe no_such_module
libkmod: ERROR ../libkmod/libkmod-config.c:673 kmod_config_parse: /etc/modprobe.d/testfile.conf line 1: ignoring bad line starting with '@'
modprobe: FATAL: Module no_such_module not found.
paranoia:/etc# rm modprobe.d/testfile.conf
paranoia:/etc# modprobe no_such_module
modprobe: FATAL: Module no_such_module not found.
paranoia:/etc# busybox modprobe no_such_module
modprobe: bad line 1: 1 tokens found, 2 needed
modprobe: module no_such_module not found in modules.dep

Notice how kmod's modprobe complains about testfile.conf, but not about
testfile.

Actual Result
=============

busybox modprobe reads any file recursively below /etc/modrobe.d as a modprobe
configuration file, unless the basename matches '.*'.

Expected Result
===============

busybox modprobe should only read files with names matching *.conf in
/etc/modprobe.d, and it should not descent into subdirectories.

Busybox version
===============

BusyBox v1.22.1 (Debian 1:1.22.0-9+deb8u1) multi-call binary.
(Debian jessie)

Additional info
===============

The relevant code appears is unchanged in current git (commit
f7466e477691fd29f47ebe8ae27489e065c69e5e, latest tag at the time I write this
is 1_23_2).

In http://git.busybox.net/busybox/tree/modutils/modprobe.c#n339 read_config()
calls recursive_action() with the ACTION_RECURSE flag.  I'm not sure whether
omitting that flag would solve the recursion problem or whether that would
introduce other problems.

In http://git.busybox.net/busybox/tree/modutils/modprobe.c#n279
config_file_action() checks whether the basename of the file starts with '.',
and if so skips the file.  I suppose that is a good place to check whether the
file ends in '.conf', too.

I'm reluctant to prepare a patch since I'm not certain how closely busybox
tries to mimic kmod's modprobe, and how much space you are willing to
sacrifice for correctness ;)

Somewhat related observations
=============================

In http://git.busybox.net/busybox/tree/modutils/modprobe.c#n624 read_config()
is called for /etc/modprobe.conf (and then for /etc/modprobe.d).  This has
the curious effect that /etc/modprobe.conf can be directory, and everything
below it is read, just as for /etc/modprobe.d.  Not sure whether that is
intended.

Also, kmod modprobe does not read /etc/modprobe.conf at all, but I guess
busybox modprobe does that for backward compatibility.

And finally modprobe(5) mentions

  /lib/modprobe.d/*.conf
  /run/modprobe.d/*.conf

which busybox modprobe does not read at all.

Context
=======

I'm running Debian jessie (testing) and recently upgraded from wheezy.  I've
had strange error messages during boot for longer than I can remember now:

  [...]
  modprobe: bad line 48: 1 tokens found, 2 needed
  modprobe: bad line 51: 1 tokens found, 2 needed
  modprobe: bad line 52: 1 tokens found, 2 needed
  modprobe: bad line 54: 1 tokens found, 2 needed
  modprobe: bad line 55: 1 tokens found, 2 needed
  modprobe: bad line 57: 1 tokens found, 2 needed

These were mostly harmless, but after the upgrade I made another attempt of
hunting them down, and traced them to busybox and files under
/etc/modprobe.d/RCS.  This was complicated by the fact that the init-ramfs
indeed contained kmod's modprobe -- but a source code search for 'bad line'
and 'tokens found' revealed that nothing in kmod can produce the above error
message.  I suppose if the shell scripts on the init-ramfs are run by busybox'
sh, then the modprobe from busybox will be preferred over the one from the
filesystem.

A further complication was that the error message gives no clue which
configuration file was causing the problem.