linux-kernel - Re: [PATCH] Fix a potential abuse of seq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202411201008.5262C14@keescook>
Date: Wed, 20 Nov 2024 10:12:40 -0800
From: Kees Cook <kees@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: David Wang <00107082@....com>, brgl@...ev.pl, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
	geert@...ux-m68k.org, linux-hardening@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH] Fix a potential abuse of seq_printf() format string in
 drivers

On Wed, Nov 20, 2024 at 08:35:38AM +0100, Linus Walleij wrote:
> On Wed, Nov 20, 2024 at 6:31 AM David Wang <00107082@....com> wrote:
> 
> > Using device name as format string of seq_printf() is proned to
> > "Format string attack", opens possibility for exploitation.
> > Seq_puts() is safer and more efficient.
> >
> > Signed-off-by: David Wang <00107082@....com>
> 
> Okay better get Kees' eye on this, he looks after string vulnerabilities.
> (But I think you're right.)

Agreed, this may lead to kernel memory content exposures. seq_puts()
looks right.

Reviewed-by: Kees Cook <kees@...nel.org>

To defend against this, it might be interesting to detect
single-argument seq_printf() usage and aim it at seq_puts()
automatically...

> 
> >  drivers/gpio/gpio-aspeed-sgpio.c            | 2 +-
> >  drivers/gpio/gpio-aspeed.c                  | 2 +-
> >  drivers/gpio/gpio-ep93xx.c                  | 2 +-
> >  drivers/gpio/gpio-hlwd.c                    | 2 +-
> >  drivers/gpio/gpio-mlxbf2.c                  | 2 +-
> >  drivers/gpio/gpio-omap.c                    | 2 +-
> >  drivers/gpio/gpio-pca953x.c                 | 2 +-
> >  drivers/gpio/gpio-pl061.c                   | 2 +-
> >  drivers/gpio/gpio-tegra.c                   | 2 +-
> >  drivers/gpio/gpio-tegra186.c                | 2 +-
> >  drivers/gpio/gpio-tqmx86.c                  | 2 +-
> >  drivers/gpio/gpio-visconti.c                | 2 +-
> >  drivers/gpio/gpio-xgs-iproc.c               | 2 +-
> >  drivers/irqchip/irq-gic.c                   | 2 +-
> >  drivers/irqchip/irq-mvebu-pic.c             | 2 +-
> >  drivers/irqchip/irq-versatile-fpga.c        | 2 +-
> >  drivers/pinctrl/bcm/pinctrl-iproc-gpio.c    | 2 +-
> >  drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 2 +-
> >  drivers/pinctrl/pinctrl-mcp23s08.c          | 2 +-
> >  drivers/pinctrl/pinctrl-stmfx.c             | 2 +-
> >  drivers/pinctrl/pinctrl-sx150x.c            | 2 +-
> >  drivers/pinctrl/renesas/pinctrl-rzg2l.c     | 2 +-
> 
> Can you split this in three patches per-subsystem?
> One for gpio, one for irqchip and one for pinctrl?
> 
> Then send to each subsystem maintainer and CC kees on
> each.
> 
> I'm just the pinctrl maintainer. The rest can be found with
> scripts/get_maintainer.pl.

Oof. That's a lot of work for a mechanical change like this. Perhaps
Greg KH can take it directly to the drivers tree instead?

-Kees

-- 
Kees Cook