linux-kernel - Re: [PATCH 1/2] Staging: comedi: comedi_fops: Change comedi_num_legacy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Mar 2017 18:16:28 +0800
From:   Cheah Kok Cheong <thrust73@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     devel@...verdev.osuosl.org, abbotti@....co.uk,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] Staging: comedi: comedi_fops: Change
 comedi_num_legacy_minors type

On Wed, Mar 08, 2017 at 10:45:26AM +0100, Greg KH wrote:
> On Wed, Mar 08, 2017 at 05:38:12PM +0800, Cheah Kok Cheong wrote:
> > Dear Greg,
> >   Thanks for taking the time to review.
> > 
> > On Tue, Mar 07, 2017 at 08:01:38PM +0100, Greg KH wrote:
> > > On Sun, Mar 05, 2017 at 03:22:32AM +0800, Cheah Kok Cheong wrote:
> > > > Change to unsigned to allow removal of negative value check in
> > > > init section.
> > > 
> > > Why?
> > > 
> > 
> > User can input a -ve number as parameter for module loading.
> 
> Then they are foolish to do so :)
> 
> > This will be caught by the mentioned check and cause loading to fail.
> > I think the original intention here is to inform user via kernel log
> > the acceptable input range.
> 
> Either is fine.
> 
> > Now if a user doesn't know how to access the log, it's of no help.
> 
> They know how to set a module parameter as root but do not know of the
> kernel log?  That's trying a bit too hard :)
> 
> > If a user does know how to access the log, probably also know how
> > to use modinfo or know that reserving a -ve number of minors is
> > not acceptable.
> > 
> > IMHO, this check is pointless and best enforced in module_param.
> 
> Ok, but it's really a minor, or no, real issue at all here.
> 

I agree with you and that's why I mentioned it's not worth doing
unless there's concurrent work in this area.

Thanks.
Brgds,
CheahKC

> thanks,
> 
> greg k-h