On Wed, Mar 11, 2020 at 05:45:31PM +0100, Takashi Iwai wrote: > On Wed, 11 Mar 2020 17:40:02 +0100, Johan Hovold wrote: > > But isn't the first snprintf() in such a sequence as much a part of the > > problem as the following ones? > > > > If the first pos = snprintf(buf, limit, ...) overflows buf, then the > > next pos += snprintf(buf, limit - pos, ...) will be called with with a > > negative size argument (i.e. a very large unsigned value), which > > effectively breaks the length check regardless of whether you replace it > > with scnprintf() or not. And all later calls will similarly continue > > writing beyond the end of buf. > > Yeah, that's the possible case although most calls are fine with it > since the limit is PAGE_SIZE or so. This might need a bit more > special care. Yeah, sure, it should be fine here too currently, even if the buffer size is defined in the caller. > > But wait a minute. This is user-space code, so there's no scnprintf(). > > Did you not compile test this? ;P > > > > In fact it seems no-one has for a while. This code is just broken and > > doesn't even compile any more. Maybe we should just drop it instead. > > Bah, I'm afraid that I overlooked this point! > > I've scraped over many places via a script-like work, and did the > compile testing of the kernel, but not about tools. If that's the > case, sorry for the mess, feel free to drop it. No worries. I'll try to take a look at the other breakages tomorrow and see if there's any point trying to salvage this at all. Johan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
