Re: [PATCH 0/3] video: Use scnprintf() for avoiding potential buffer overflow

On Tue, Mar 31, 2020 at 01:59:32PM +0200, Bartlomiej Zolnierkiewicz wrote:

On 3/27/20 9:25 AM, Takashi Iwai wrote:

quoted

On Fri, 20 Mar 2020 14:42:51 +0100,
Bartlomiej Zolnierkiewicz wrote:

quoted

On 3/19/20 4:49 PM, Takashi Iwai wrote:

quoted

On Wed, 11 Mar 2020 10:32:27 +0100,
Takashi Iwai wrote:

quoted

Hi,

here is a series of trivial patches just to convert suspicious
snprintf() usages with the more safer one, scnprintf().


Takashi

=> >>>>
Takashi Iwai (3):
  video: omapfb: Use scnprintf() for avoiding potential buffer overflow
  video: omap2: Use scnprintf() for avoiding potential buffer overflow
  video: uvesafb: Use scnprintf() for avoiding potential buffer overflow

 drivers/video/fbdev/omap/omapfb_main.c          | 14 +++++++-------
 drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c |  8 ++++----
 drivers/video/fbdev/uvesafb.c                   |  2 +-
 3 files changed, 12 insertions(+), 12 deletions(-)

Just a gentle ping about those patches.
Let me know if any further changes needed.

Patches #1-3 queued for v5.7, thanks!

I still don't see those in linux-next as of today.
Could you check it?

They are in drm-misc/drm-misc-next branch but for some reason linux-next
uses drm-misc/for-linux-next one.

Daniel, is this correct?

[ I couldn't find anything about for-linux-next branch at
  https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html ]

Yup, once drm is frozen for features we push drm-misc-next-fixes to
for-linux-next, but the main branch drm-misc-next is still open (but will
be delayed to the subsequent kernel merge window). That's why the "where
do I apply a bugfix" diagram in our docs isn't that simply (if you pick
the wrong branch it's going to be one kernel release too late). This
freeze generally happans around -rc6/7 or so, a bit ahead of when the
merge windo opens.

iow the above stuff is queued for 5.8, and should show up in linux-next
right after -rc1 is out.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch