public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: akpm@osdl.org, aebr@win.tue.nl, vojtech@suse.cz,
	torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix NR_KEYS off-by-one error
Date: Fri, 30 Jul 2004 00:27:06 -0700	[thread overview]
Message-ID: <20040730002706.2330974d.pj@sgi.com> (raw)
In-Reply-To: <87pt6e2sm3.fsf@devron.myhome.or.jp>

Andrew writes:
> Hate to be a bore, but I'm still waiting for a definitive patch ;)

OGAWA Hirofumi writes:
> Could you please post your lastest patch? It seems that my patch does
> not satisfy peoples.

Hmmm ...

As is often the case, Andrew knows more than he lets on.


OGAWA,

I cannot post a latest patch.  I do not know enough to do so.

I attempted some code readability comments, but probably I should not
have, since I don't have the knowledge of this code that I should have
in order to test it, nor to know by reading it what works.

You replied, a couple of messages ago, with entirely sensible comments
to my posting.  Since then, I have been doing my best to remove myself
from this thread.

Unless you have something else you wish to propose, please tell Andrew
to go with your patch, which (just to avoid confusion) I copy again
below.

Your patch satisfies me just fine now.

Please let Andrew know if he should take it.

My apologies for making a confusion of this.

Thank-you for your good work and your patience.


[PATCH] Fix NR_KEYS off-by-one error

KDGKBENT ioctl can use 256 entries (0-255), but it was defined as
key_map[NR_KEYS] (NR_KEYS == 255). The code seems also thinking it's 256.

	key_map[0] = U(K_ALLOCATED);
	for (j = 1; j < NR_KEYS; j++)
		key_map[j] = U(K_HOLE);

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

 drivers/char/vt_ioctl.c  |    6 ++++++
 include/linux/keyboard.h |    2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff -puN include/linux/keyboard.h~nr_keys-off-by-one include/linux/keyboard.h
--- linux-2.6.8-rc2/include/linux/keyboard.h~nr_keys-off-by-one	2004-07-28 03:37:12.000000000 +0900
+++ linux-2.6.8-rc2-hirofumi/include/linux/keyboard.h	2004-07-28 03:37:12.000000000 +0900
@@ -16,7 +16,7 @@
 
 #define NR_SHIFT	9
 
-#define NR_KEYS		255
+#define NR_KEYS		256
 #define MAX_NR_KEYMAPS	256
 /* This means 128Kb if all keymaps are allocated. Only the superuser
 	may increase the number of keymaps beyond MAX_NR_OF_USER_KEYMAPS. */
diff -puN drivers/char/vt_ioctl.c~nr_keys-off-by-one drivers/char/vt_ioctl.c
--- linux-2.6.8-rc2/drivers/char/vt_ioctl.c~nr_keys-off-by-one	2004-07-29 01:31:12.000000000 +0900
+++ linux-2.6.8-rc2-hirofumi/drivers/char/vt_ioctl.c	2004-07-29 01:35:23.000000000 +0900
@@ -83,6 +83,12 @@ do_kdsk_ioctl(int cmd, struct kbentry __
 	if (copy_from_user(&tmp, user_kbe, sizeof(struct kbentry)))
 		return -EFAULT;
 
+#if NR_KEYS != 256 || MAX_NR_KEYMAPS != 256
+#error "you should check this too"
+	if (i >= NR_KEYS || s >= MAX_NR_KEYMAPS)
+		return -EINVAL;
+#endif
+
 	switch (cmd) {
 	case KDGKBENT:
 		key_map = key_maps[s];
_
-

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

  reply	other threads:[~2004-07-30  7:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-16 16:35 [PATCH] Fix NR_KEYS off-by-one error OGAWA Hirofumi
2004-07-16 16:44 ` Vojtech Pavlik
2004-07-16 17:18   ` OGAWA Hirofumi
2004-07-16 20:15   ` Andries Brouwer
2004-07-17  6:23     ` OGAWA Hirofumi
2004-07-26 22:43       ` Andrew Morton
2004-07-27 13:46         ` Vojtech Pavlik
2004-07-27 16:37           ` OGAWA Hirofumi
2004-07-27 17:54             ` Vojtech Pavlik
2004-07-27 18:35               ` OGAWA Hirofumi
2004-07-28 11:51       ` Andries Brouwer
2004-07-28 16:46         ` OGAWA Hirofumi
2004-07-28 20:42           ` Paul Jackson
2004-07-29  4:10             ` OGAWA Hirofumi
2004-07-29  6:15               ` Paul Jackson
2004-07-29  9:24                 ` OGAWA Hirofumi
2004-07-29  9:49                   ` Paul Jackson
2004-07-29 23:24                     ` Andrew Morton
2004-07-29 23:51                       ` Paul Jackson
2004-07-30  1:25                         ` OGAWA Hirofumi
2004-07-30  7:27                           ` Paul Jackson [this message]
2004-07-30  8:07                             ` Vojtech Pavlik
2004-07-30  8:41                               ` Andries Brouwer
2004-07-30  8:51                                 ` Vojtech Pavlik
2004-07-30  9:03                                 ` Vojtech Pavlik

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=20040730002706.2330974d.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=aebr@win.tue.nl \
    --cc=akpm@osdl.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=vojtech@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox