[PATCH 0/9] -stable review
Chris Wright
There are 9 patches in this series, all will be posted as a response to
this one. If anyone has any issues with these being applied, please let
us know. If anyone is a maintainer of the proper subsystem, and wants
to add a signed-off-by: line to the patch, please respond with it.
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email sta...@kernel.org
to add your name to the list. If you want to be off the reviewer list,
also email us.
Responses should be made by Sat Sep 8 01:00 2005 UTC. Anything received
after that time, might be too late.
thanks,
the -stable release team
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Chris Wright
catching oversight.
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Al Viro <av...@redhat.com>
Fix unchecked __get_user that could be tricked into generating a
memory read on an arbitrary address. The result of the read is not
returned directly but you may be able to divine some information about
it, or use the read to cause a crash on some architectures by reading
hardware state. CAN-2005-2492.
Fix from Al Viro, ack from Dave Miller.
Signed-off-by: Chris Wright <chr...@osdl.org>
---
net/ipv4/raw.c | 2 +-
net/ipv6/raw.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.13.y/net/ipv4/raw.c
===================================================================
--- linux-2.6.13.y.orig/net/ipv4/raw.c
+++ linux-2.6.13.y/net/ipv4/raw.c
@@ -358,7 +358,7 @@ static void raw_probe_proto_opt(struct f
if (type && code) {
get_user(fl->fl_icmp_type, type);
- __get_user(fl->fl_icmp_code, code);
+ get_user(fl->fl_icmp_code, code);
probed = 1;
}
break;
Index: linux-2.6.13.y/net/ipv6/raw.c
===================================================================
--- linux-2.6.13.y.orig/net/ipv6/raw.c
+++ linux-2.6.13.y/net/ipv6/raw.c
@@ -619,7 +619,7 @@ static void rawv6_probe_proto_opt(struct
if (type && code) {
get_user(fl->fl_icmp_type, type);
- __get_user(fl->fl_icmp_code, code);
+ get_user(fl->fl_icmp_code, code);
probed = 1;
}
break;
Henrik Persson
> This is the start of the stable review cycle for the 2.6.13.1 release.
> There are 9 patches in this series, all will be posted as a response to
> this one. If anyone has any issues with these being applied, please let
> us know. If anyone is a maintainer of the proper subsystem, and wants
> to add a signed-off-by: line to the patch, please respond with it.
I didn't see the patch from Ivan Kokshaysky (
http://marc.theaimsgroup.com/?l=linux-kernel&m=112541348008047&w=2 )
included.. Without this one my laptop will freeze and die when inserting
a something into the cardbus slot, so I would say that it would kind of
fit in there.
Any reason why it's not included?
--
Henrik
Chris Wright
*
> I didn't see the patch from Ivan Kokshaysky (
> http://marc.theaimsgroup.com/?l=linux-kernel&m=112541348008047&w=2 )
> included.. Without this one my laptop will freeze and die when inserting
> a something into the cardbus slot, so I would say that it would kind of
> fit in there.
>
> Any reason why it's not included?
It's in there, number 4 in the series.
thanks,
-chris
Chris Wright
There are 11 patches in this series, all will be posted as a response to
this one. If anyone has any issues with these being applied, please let
us know. If anyone is a maintainer of the proper subsystem, and wants
to add a signed-off-by: line to the patch, please respond with it.
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email sta...@kernel.org
to add your name to the list. If you want to be off the reviewer list,
also email us.
Responses should be made by Sat Sep 17 01:00 2005 UTC. Anything received
after that time, might be too late.
thanks,
the -stable release team
--
David Lang
well? if so can they be fixed at the same time?
David Lang
On Wed, 14 Sep 2005, Chris Wright wrote:
> Date: Wed, 14 Sep 2005 18:03:47 -0700
> From: Chris Wright <chr...@osdl.org>
> To: linux-...@vger.kernel.org, sta...@kernel.org
> Cc: Justin Forbes <jmfo...@linuxtx.org>,
> Zwane Mwaikambo <zw...@arm.linux.org.uk>, Theodore Ts'o <ty...@mit.edu>,
> Randy Dunlap <rdu...@xenotime.net>,
> Chuck Wolber <chu...@quantumlinux.com>, torv...@osdl.org, ak...@osdl.org,
> al...@lxorguk.ukuu.org.uk, Linus Torvalds <torv...@osdl.org>,
> Chris Wright <chr...@osdl.org>
> Subject: [PATCH 04/11] hpt366: write the full 4 bytes of ROM address,
> not just low 1 byte
>
> -stable review patch. If anyone has any objections, please let us know.
> ------------------
>
> This is one heck of a confused driver. It uses a byte write to a dword
> register to enable a ROM resource that it doesn't even seem to be using.
>
> "Lost and wandering in the desert of confusion"
>
> Signed-off-by: Linus Torvalds <torv...@osdl.org>
> Signed-off-by: Chris Wright <chr...@osdl.org>
> ---
> drivers/ide/pci/hpt366.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.13.y/drivers/ide/pci/hpt366.c
> ===================================================================
> --- linux-2.6.13.y.orig/drivers/ide/pci/hpt366.c
> +++ linux-2.6.13.y/drivers/ide/pci/hpt366.c
> @@ -1334,9 +1334,13 @@ static int __devinit init_hpt366(struct
> static unsigned int __devinit init_chipset_hpt366(struct pci_dev *dev, const char *name)
> {
> int ret = 0;
> - /* FIXME: Not portable */
> +
> + /*
> + * FIXME: Not portable. Also, why do we enable the ROM in the first place?
> + * We don't seem to be using it.
> + */
> if (dev->resource[PCI_ROM_RESOURCE].start)
> - pci_write_config_byte(dev, PCI_ROM_ADDRESS,
> + pci_write_config_dword(dev, PCI_ROM_ADDRESS,
> dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
>
> pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, (L1_CACHE_BYTES / 4));
>
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
Andrew Morton
>
> didn't Linus find similar bugs in a couple of the other hpt drivers as
> well? if so can they be fixed at the same time?
Adam Kropelin did a sweep and picked up four similar cases. I queued the
patches and they should be considered for 2.6.13.3
David Lang
> David Lang <dl...@digitalinsight.com> wrote:
>>
>> didn't Linus find similar bugs in a couple of the other hpt drivers as
>> well? if so can they be fixed at the same time?
>
> Adam Kropelin did a sweep and picked up four similar cases. I queued the
> patches and they should be considered for 2.6.13.3
>
Thanks,
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
Chris Wright
> didn't Linus find similar bugs in a couple of the other hpt drivers as
> well? if so can they be fixed at the same time?
Yes, and they're in this series. This patch does:
drivers/ide/pci/hpt366.c
And patch 10/11 does:
drivers/ide/pci/cmd64x.c
drivers/ide/pci/hpt34x.c
Additionally, the sungem (5/11) and sunhme (6/11) changes are fallout
from PCI_ROM fixes.
I believe the remainder of the PCI_ROM related patches were primarily
for consistency.
thanks,
-chris
Alexander Nyberg
> This is the start of the stable review cycle for the 2.6.13.2 release.
> There are 11 patches in this series, all will be posted as a response to
> this one. If anyone has any issues with these being applied, please let
> us know. If anyone is a maintainer of the proper subsystem, and wants
> to add a signed-off-by: line to the patch, please respond with it.
>
> These patches are sent out with a number of different people on the
> Cc: line. If you wish to be a reviewer, please email sta...@kernel.org
> to add your name to the list. If you want to be off the reviewer list,
> also email us.
>
This might be worth putting in too (has been hit by at least two people
in the real world etc.)
tree e3a704026e65bf6fea0c7747f0fb75a506f54127
parent 32a3658533c6f4c6bf370dd730213e802464ef9b
author Alexander Nyberg <al...@telia.com> Wed, 14 Sep 2005 18:54:06 +0200
committer Linus Torvalds <torv...@g5.osdl.org> Thu, 15 Sep 2005 00:26:34 -0700
[PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON
It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable
and can trigger due to the test itself being racy.
de_thread() does
while (atomic_read(&sig->count) > count) {
}
.....
.....
BUG_ON(!thread_group_empty(current));
but release_task does
write_lock_irq(&tasklist_lock)
__exit_signal
(this is where atomic_dec(&sig->count) is run)
__exit_sighand
__unhash_process
takes write lock on tasklist_lock
remove itself out of PIDTYPE_TGID list
write_unlock_irq(&tasklist_lock)
so there's a clear (although small) window between the
atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the
thread.
And actually there is no need for all threads to have exited at this
point, so we simply kill the BUG_ON.
Big thanks to Marc Lehmann who provided the test-case.
Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170)
Signed-off-by: Alexander Nyberg <al...@telia.com>
Cc: Roland McGrath <rol...@redhat.com>
Cc: Andrew Morton <ak...@osdl.org>
Cc: Ingo Molnar <mi...@elte.hu>
Acked-by: Andi Kleen <a...@suse.de>
Signed-off-by: Linus Torvalds <torv...@osdl.org>
fs/exec.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -745,8 +745,8 @@ static inline int de_thread(struct task_
}
/*
- * Now there are really no other threads at all,
- * so it's safe to stop telling them to kill themselves.
+ * There may be one thread left which is just exiting,
+ * but it's safe to stop telling the group to kill themselves.
*/
sig->flags = 0;
@@ -785,7 +785,6 @@ no_thread_group:
kmem_cache_free(sighand_cachep, oldsighand);
}
- BUG_ON(!thread_group_empty(current));
BUG_ON(!thread_group_leader(current));
return 0;
Martin Mares
> This is one heck of a confused driver. It uses a byte write to a dword
> register to enable a ROM resource that it doesn't even seem to be using.
Once upon a time when I was the PCI maintainer, I was arguing with Andre
Hedrick about this one and he kept asserting that enabling the ROM is
necessary to make the chip work. Not that I believe it :)
Have a nice fortnight
--
Martin `MJ' Mares <m...@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Never make any mistaeks.
David Lang
> * David Lang (dl...@digitalinsight.com) wrote:
>> didn't Linus find similar bugs in a couple of the other hpt drivers as
>> well? if so can they be fixed at the same time?
>
> Yes, and they're in this series. This patch does:
>
> drivers/ide/pci/hpt366.c
>
> And patch 10/11 does:
>
> drivers/ide/pci/cmd64x.c
> drivers/ide/pci/hpt34x.c
>
> Additionally, the sungem (5/11) and sunhme (6/11) changes are fallout
> from PCI_ROM fixes.
>
> I believe the remainder of the PCI_ROM related patches were primarily
> for consistency.
sorry about the noise, I read through all the descriptions looking for
these, but I hadn't read all the patches.
David Lang
P.S. thanks to the kernel team for catching this before I got a chance to
install .13 on my system that has a hpt374 controller :-)
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
Chris Wright
> This might be worth putting in too (has been hit by at least two people
> in the real world etc.)
Yes, I'd tagged it to ping you. Thanks, added to -stable queue.
-chris