Re: [PATCH 2/2] configfs: fix kernel infoleak through user-controlled format string

[Greg Kroah-Hartman]

On Tue, Jul 07, 2015 at 10:28:00PM +0800, Nicolas Iooss wrote:
> Some modules call config_item_init_type_name() and
> config_group_init_type_name() with parameter "name" directly controlled
> by userspace.  These two functions call config_item_set_name() with this
> name used as a format string, which can be used to leak information such
> as content of the stack to userspace.
> 
> For example, make_netconsole_target() in netconsole module calls
> config_item_init_type_name() with the name of a newly-created directory.
> This means that the following commands give some unexpected output, with
> configfs mounted in /sys/kernel/config/ and on a system with a
> configured eth0 ethernet interface:
> 
>     # modprobe netconsole
>     # mkdir /sys/kernel/config/netconsole/target_%lx
>     # echo eth0 > /sys/kernel/config/netconsole/target_%lx/dev_name
>     # echo 1 > /sys/kernel/config/netconsole/target_%lx/enabled
>     # echo eth0 > /sys/kernel/config/netconsole/target_%lx/dev_name
>     # dmesg |tail -n1
>     [  142.697668] netconsole: target (target_ffffffffc0ae8080) is
>     enabled, disable to update parameters
> 
> The directory name is correct but %lx has been interpreted in the
> internal item name, displayed here in the error message used by
> store_dev_name() in drivers/net/netconsole.c.
> 
> To fix this, update every caller of config_item_set_name to use "%s"
> when operating on untrusted input.
> 
> This issue was found using -Wformat-security gcc flag, once a __printf
> attribute has been added to config_item_set_name().
> 
> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@xxxxxxx>
> ---
>  drivers/usb/gadget/configfs.c | 2 +-
>  fs/configfs/item.c            | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)


Nice catch:

Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/