On Mon 2022-05-23 12:39:12, Kees Cook wrote: > On Sat, May 21, 2022 at 11:07:52PM -0700, Christoph Hellwig wrote: > > On Fri, May 20, 2022 at 02:06:56PM +0530, Maninder Singh wrote: > > > kallsyms functionality depends on KSYM_NAME_LEN directly. > > > but if user passed array length lesser than it, sprintf > > > can cause issues of buffer overflow attack. > > > > > > So changing *sprint* and *lookup* APIs in this patch set > > > to have buffer size as an argument and replacing sprintf with > > > scnprintf. > > > > This is still a pretty horrible API. Passing something like > > a struct seq_buf seems like the much better API here. Also with > > the amount of arguments and by reference passing it might be worth > > to pass them as a structure while you're at it. > > Yeah, I agree. It really seems like seq_buf would be nicer. There is a new patchset that is trying to use this kind of buffer in vsprintf. It introduces another buffer struct because vsprintf() needs a bit different semantic than the one used in seq_buf. But it actually replaces seq_buf() in the end. I am not sure if this is the right approach. Anyway, the initial API is very simple, see https://lore.kernel.org/r/20220604193042.1674951-2-kent.overstreet@xxxxxxxxx And it makes the internal vsprintf() API more sane, see https://lore.kernel.org/r/20220604193042.1674951-4-kent.overstreet@xxxxxxxxx It would eventually solve also concerns about the kallsysms API. Any comments on the new printbuf API are much appreaciated. Best Regards, Petr
