All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Corentin LABBE <clabbe.montjoie@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	airlied@linux.ie, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 1/1] drm: modes: fix DRM modes analysis regression
Date: Thu, 10 Dec 2015 09:04:43 +0100	[thread overview]
Message-ID: <20151210080443.GS20822@phenom.ffwll.local> (raw)
In-Reply-To: <56687CEB.9060007@gmail.com>

On Wed, Dec 09, 2015 at 08:11:39PM +0100, Corentin LABBE wrote:
> Le 09/12/2015 16:32, Jani Nikula a écrit :
> > On Wed, 09 Dec 2015, LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
> >> My latest commit introduce some case where a valid mode, could be
> >> rejected.
> >> simple_strtox functions stop at first non-digit character, but kstrtox not.
> >> So args like "video=HDMI-A-1:720x480-16@60" will be reject when checking 16@.
> >> The proper solution is to store digits in a specific buffer.
> > 
> > Or to revert regressing commit...? Your original commit complicated the
> > already complicated function, and this one makes it more so. What is the
> > benefit?
> > 
> 
> The benefit is to remove a function marked obsolete who do not said if the conversation is successful or not.
> But I understand that the way I have done it was not the best one.
> If the maintainer want it, I will send a patch for reverting the first patch.

Given that nothin bad happens if we misparse the number (black screen) and
there's no screen resolution even close to the limit of what can be
parsed, I think reverting is the right action.

Carefully parsing userspace input makes sense. But this is the kernel
cmdline, if your attacker can change that you've lost no matter what.

Please send in the revert with a short summary of the discussion here.

Thanks, Daniel

> 
> >> Fixes: 52157a4ca396 ("drm: modes: replace simple_strtoul by kstrtouint")
> > 
> > For me the commit id is cc344980c76748e57c9c03100c2a14d36ab00334.
> 
> Oups, I took commit id from my local git.
> 
> Regards
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Corentin LABBE <clabbe.montjoie@gmail.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] drm: modes: fix DRM modes analysis regression
Date: Thu, 10 Dec 2015 09:04:43 +0100	[thread overview]
Message-ID: <20151210080443.GS20822@phenom.ffwll.local> (raw)
In-Reply-To: <56687CEB.9060007@gmail.com>

On Wed, Dec 09, 2015 at 08:11:39PM +0100, Corentin LABBE wrote:
> Le 09/12/2015 16:32, Jani Nikula a écrit :
> > On Wed, 09 Dec 2015, LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
> >> My latest commit introduce some case where a valid mode, could be
> >> rejected.
> >> simple_strtox functions stop at first non-digit character, but kstrtox not.
> >> So args like "video=HDMI-A-1:720x480-16@60" will be reject when checking 16@.
> >> The proper solution is to store digits in a specific buffer.
> > 
> > Or to revert regressing commit...? Your original commit complicated the
> > already complicated function, and this one makes it more so. What is the
> > benefit?
> > 
> 
> The benefit is to remove a function marked obsolete who do not said if the conversation is successful or not.
> But I understand that the way I have done it was not the best one.
> If the maintainer want it, I will send a patch for reverting the first patch.

Given that nothin bad happens if we misparse the number (black screen) and
there's no screen resolution even close to the limit of what can be
parsed, I think reverting is the right action.

Carefully parsing userspace input makes sense. But this is the kernel
cmdline, if your attacker can change that you've lost no matter what.

Please send in the revert with a short summary of the discussion here.

Thanks, Daniel

> 
> >> Fixes: 52157a4ca396 ("drm: modes: replace simple_strtoul by kstrtouint")
> > 
> > For me the commit id is cc344980c76748e57c9c03100c2a14d36ab00334.
> 
> Oups, I took commit id from my local git.
> 
> Regards
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2015-12-10  8:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09 13:30 [PATCH v2 0/1] drm: modes: fix DRM modes analysis regression LABBE Corentin
2015-12-09 13:30 ` [PATCH v2 1/1] " LABBE Corentin
2015-12-09 15:32   ` Jani Nikula
2015-12-09 15:32     ` Jani Nikula
2015-12-09 19:11     ` Corentin LABBE
2015-12-09 19:11       ` Corentin LABBE
2015-12-10  8:04       ` Daniel Vetter [this message]
2015-12-10  8:04         ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151210080443.GS20822@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@linux.ie \
    --cc=clabbe.montjoie@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.