All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaco Kroon <jaco@kroon.co.za>
To: kernel-janitors@vger.kernel.org
Subject: Re: [KJ] [patch] potential data-corruption fix in md.c
Date: Fri, 02 Dec 2005 19:19:03 +0000	[thread overview]
Message-ID: <43909E27.805@kroon.co.za> (raw)
In-Reply-To: <8378.192.96.150.57.1133516341.squirrel@mail.interexcel.co.za>


[-- Attachment #1.1: Type: text/plain, Size: 1580 bytes --]

Alexey Dobriyan wrote:
> On Fri, Dec 02, 2005 at 06:38:53PM +0100, Jesper Juhl wrote:
> 
>>On 12/2/05, Jaco Kroon <jaco@kroon.co.za> wrote:
>>
>>>Fix a check whereby a negative personality number passed to either
>>>register_md_personality or unregister_md_personality could potentially
>>>cause data corruption.
> 
> 
>>>--- linux-2.6.14/drivers/md/md.c.orig
>>>+++ linux-2.6.14/drivers/md/md.c
>>>@@ -3425,7 +3425,7 @@
>>>
>>> int register_md_personality(int pnum, mdk_personality_t *p)
>>> {
>>>-       if (pnum >= MAX_PERSONALITY) {
>>>+       if (pnum < 0 || pnum >= MAX_PERSONALITY) {
>>>                printk(KERN_ERR
>>>                       "md: tried to install personality %s as nr %d, but max is %lu\n",
>>>                       p->name, pnum, MAX_PERSONALITY-1);
>>>@@ -3446,7 +3446,7 @@
>>>
>>> int unregister_md_personality(int pnum)
>>> {
>>>-       if (pnum >= MAX_PERSONALITY)
>>>+       if (pnum < 0 || pnum >= MAX_PERSONALITY)
>>>                return -EINVAL;
>>>
>>
>>MAX_PERSONALITY that pnum is compared to is defined as
>>
>>#define MAX_PERSONALITY   11UL
>>
>>so might it make more sense to just switch pnum to be an "unsigned
>>long" instead of adding <0 checks?
> 
> 
> It is int in other md files. So, one may want to change int to bitwised
> enum. Or add the check.

Or just cast to (unsigned int) for the check?
Perhaps that happens implicitly?
Would that be compiler dependant?
Do we care about anything but gcc?

-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3166 bytes --]

[-- Attachment #2: Type: text/plain, Size: 168 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

  parent reply	other threads:[~2005-12-02 19:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-02  9:39 [KJ] [patch] potential data-corruption fix in md.c Jaco Kroon
2005-12-02 17:38 ` Jesper Juhl
2005-12-02 18:57 ` Alexey Dobriyan
2005-12-02 19:19 ` Jaco Kroon [this message]
2005-12-02 19:45 ` Håkon Løvdal
2005-12-02 20:48 ` Jaco Kroon

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=43909E27.805@kroon.co.za \
    --to=jaco@kroon.co.za \
    --cc=kernel-janitors@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.