Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: iac594737:Fastmail
Date:   Tue, 13 Jun 2023 11:35:05 -0400
From:   Demi Marie Obenour <demi@invisiblethingslab.com>
To:     David Laight <David.Laight@aculab.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Alexey Dobriyan <adobriyan@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Hans de Goede <hdegoede@redhat.com>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
        Lee Jones <lee@kernel.org>, Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>,
        Petr Mladek <pmladek@suse.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH v3 0/4] Make sscanf() stricter
Message-ID: <ZIiMrDxI5Ts0s8fK@itl-email>
References: <6ab6adce-2318-4ae6-bde6-4317485639fd@p183>
 <ZId/IA41c2sJyvE0@itl-email>
 <ZIeHfBf3aB3vUgRM@smile.fi.intel.com>
 <ZIeMyQXU49OcoxY2@itl-email>
 <ec3d7ebe62654e949329785bb32c3822@AcuMS.aculab.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="fNICznYAU3QlUDGM"
Content-Disposition: inline
In-Reply-To: <ec3d7ebe62654e949329785bb32c3822@AcuMS.aculab.com>
Precedence: bulk


--fNICznYAU3QlUDGM
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 Jun 2023 11:35:05 -0400
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: David Laight <David.Laight@aculab.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Hans de Goede <hdegoede@redhat.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Lee Jones <lee@kernel.org>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH v3 0/4] Make sscanf() stricter

On Tue, Jun 13, 2023 at 01:02:59PM +0000, David Laight wrote:
> From: Demi Marie Obenour
> > Sent: 12 June 2023 22:23
> ....
> > sscanf(), except to the extent that -Werror=3Dformat can keep working.
> > Userspace sscanf() is almost useless: it has undefined behavior on
> > integer overflow and swallows spaces that should usually be rejected.
>=20
> scanf() is designed for parsing space separated data.
> Eating spaces it part of its job description.
>=20
> 	David

In this case I would prefer to have two versions: one that eats spaces
and one that does not.  For instance, I don=E2=80=99t think any user of
xenbus_scanf() wants the space-swallowing behavior.  This can be worked
around in xenbus_scanf(), of course, by having it reject strings with
spaces (as determened by isspace()) before calling vsscanf().
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--fNICznYAU3QlUDGM
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmSIjKwACgkQsoi1X/+c
IsH7BBAAvFNPcgApcQwpZ3D3vyZvEJ6//ENiuEPS3e9FzSqjwejzAuIzUMK15zNv
mgfy2bVAeWvpxNgvYE6tuJ182pcZosJgxnzi5R2a5ft9eEs2OvNQgUskgxD+BT1C
4sPw09VkTVrYQ+UO7wQ+fyM6LsLF+G3fukQP9wrejFETpS9Sk+4yonELFHlvN13K
WJ7lU56W8QVnyd8nDyVo7v/MeXAPITGyFPAV7zN3uP9NsFJmAcR1QCP+6WubO5rm
67VcxkLSvxh+ch8gttagXNGZTGLnjQaaDU3VygNCAEV+vOJe4SUcDSKC5VhKMoad
Ew6Ki2fiA/zMk1jJvBCmN6JU+8JyVPU2t2ITccVS9VG/S2eTQrwTlHjba16IRTTV
D9Ai5CdkI9aYJk482BlurVYjoYPQqFrpFDOw+nhxclhvdruxSmo3us1jwPyoLVJY
iTbRoyLKV5NnOb+AkVtGN6XqgBklPCSZty8QWPts3tXvzt30miS+4tL8+vUH853s
aXsQtFxmQ4iw3GdQyjyuY0DnKzTw3s7jKHnm6H4O5iokF8f2YfMNxAj5NfeginVo
lrDgGhnbIOknNK6azyx0jGEmzWQUzqQLGHYn2GWCI8/90BACz6Cp6/beH6HF3VO6
oC/WHx1YtttkGKO+R1yEp9lMKy/elfIYJGVBxHjoJoR0A5VPr8Y=
=Uv3f
-----END PGP SIGNATURE-----

--fNICznYAU3QlUDGM--