Re: Preparing the first security update for kernel-source-2.6.8
On Fri, Jul 08, 2005 at 11:06:49AM -0600, dann frazier wrote: On Fri, 2005-07-08 at 11:59 +0900, Horms wrote: On the grounds that a) it fixes a security bug and b) it doesn't appear to change the ABI, yes, please go for it. kernel/sarge-security/kernel/source currently has testing-security instead of UNRELEASED in the changelog in svn - should I put these patches in 2.6.8-15sarge1, or should I start a sarge2? I'll add them to trunk in the meantime. 2.6.8-15sarge1 was never released, although it was packaged up and intended for release, instead 2.6.8-16 snuck in. I think the best place to put pached now is in the main svn directory, as 2.6.8-17. I have already started this. The security update should probably be called 2.6.8-16sarge1, but unless Frank has other ideas, I think that should basically be a paired down package based on whatever we have for 2.6.8-17 at the time. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the first security update for kernel-source-2.6.8
On Thu, Jul 07, 2005 at 03:14:02PM -0600, dann frazier wrote: On Wed, 2005-06-29 at 16:09 +0900, Horms wrote: On Wed, Jun 29, 2005 at 11:14:20AM +0900, Horms wrote: On Tue, Jun 28, 2005 at 10:36:15PM +0200, Frederik Schueler wrote: Hello, I would like to start preparing a seurity update for kernel-source-2.6.8 in sarge, wich released with version 2.6.8-16. In sarge-security we have an old 2.6.15sarge1 wich never got released. Does anyone object if I update those sources to the revision in sarge, and we start building 2.6.8-16sarge1 from it? I already got some patches from the ubuntu 2.6.8 kernel package addressing the following 5 issues: CAN-2005-0756 CAN-2005-1265 CAN-2005-1762 CAN-2005-1763 CAN-2005-1765 and these 3 still need to be addressed: CAN-2005-1764 CAN-2005-0449 #295949 CAN-2005-0356 #310804 if nobody objects, I would like to commit my changes. Dann, could you comment on the need for backporting the patch below form 2.6.12.1. It does not apply cleanly to 2.6.8 as there seem to have been a bunch of other patches in the mean time. hey Horms, This patch appears to be relevant for 2.6.8. It depends on two earlier patches; one of which fixes what looks like another security issue to me - kernel is accessing unchecked addresses provided by userspace[1]. I've backported the fix for CAN-2005-1764 to our 2.6.8 with [1] applied (attached). I'd recommend applying both of these patches to our tree. Any objections? [1] http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|src/|src/arch|src/arch/ia64|src/arch/ia64/kernel|related/arch/ia64/kernel/ptrace.c On the grounds that a) it fixes a security bug and b) it doesn't appear to change the ABI, yes, please go for it. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the first security update for kernel-source-2.6.8
On Wed, Jun 29, 2005 at 06:57:26PM -0400, Michael Stone wrote: How are kernel updates being coordinated for sarge? Is there an overview of who's doing what? I am not aware of any coordination effors in regards to this. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the first security update for kernel-source-2.6.8
On Thu, Jun 30, 2005 at 04:24:32PM -0400, Joey Hess wrote: Horms wrote: * arch-x86_64-kernel-ptrace-canonical-rip-1.dpatch, arch-x86_64-kernel-ptrace-canonical-rip-2.dpatch This works around an AMD Erratum by checking if the ptrace RIP is canonical. (Simon Horman) * [SECURITY] arch-x86_64-kernel-smp-boot-race.dpatch Keep interrupts disabled during smp bootup This avoids a race that breaks SMP bootup on some machines. (Simon Horman) * [SECURITY] arch-x86_64-mm-ioremap-page-lookup.dpatch Don't look up struct page pointer of physical address in iounmap as it may be in a memory hole not mapped in mem_map and that causes the hash lookup to go off to nirvana. (Simon Horman) Does anyone know what CVE ids apply to these holes? I'm guessing that it's some of the reserved IDs CAN-2005-1765, CAN-2005-1764, CAN-2005-1763, and CAN-2005-1762, but I'm not sure which fix was left out or which fix applies to which hole, since there's not much public information. Having bugs in the bts would make tracking this stuff ever so much easier. Hi Joey, I am not sure either. I think that having references, like the CAN entry, for bugs is very important. But undfortunately CAN entries tend to be somewhat vauge, they are rarely noted in upstream bug fixes and sometimes they lie reserved for a long time. In short, associating fixes with CAN entries isn't as easy as it should be. If anyone has information that relates fixes to CAN entries, I am more than happy to add this to the changelog. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the first security update for kernel-source-2.6.8
On Wed, Jun 29, 2005 at 11:14:20AM +0900, Horms wrote:
On Tue, Jun 28, 2005 at 10:36:15PM +0200, Frederik Schueler wrote:
Hello,
I would like to start preparing a seurity update for kernel-source-2.6.8
in sarge, wich released with version 2.6.8-16.
In sarge-security we have an old 2.6.15sarge1 wich never got released.
Does anyone object if I update those sources to the revision in sarge,
and we start building 2.6.8-16sarge1 from it?
I already got some patches from the ubuntu 2.6.8 kernel package addressing
the following 5 issues:
CAN-2005-0756
CAN-2005-1265
CAN-2005-1762
CAN-2005-1763
CAN-2005-1765
and these 3 still need to be addressed:
CAN-2005-1764
CAN-2005-0449 #295949
CAN-2005-0356 #310804
if nobody objects, I would like to commit my changes.
Dann, could you comment on the need for backporting the patch below
form 2.6.12.1. It does not apply cleanly to 2.6.8 as there
seem to have been a bunch of other patches in the mean time.
--
Horms
commit df0112ae92e768bda81105cff85d7c8e46004d7b
tree 98f262f17071a9ab1d1fa1ffa42085faaffb6b12
parent fe3d5c8793fcaf33c5d3118a7f3ffc135eadaf4d
author Matthew Chapman [EMAIL PROTECTED] 1119325981 -0700
committer Chris Wright [EMAIL PROTECTED] 1119468770 -0700
[PATCH] ia64 ptrace + sigrestore_context (CAN-2005-1761)
This patch fixes handling of accesses to ar.rsc via ptrace
restore_sigcontext
Signed-off-by: Matthew Chapman [EMAIL PROTECTED]
Acked-by: David Mosberger [EMAIL PROTECTED]
Acked-by: Tony Luck [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
I:100644 100644 575a8f657b3129bacc8ec2979470ecc84c9b7b3f
6d57aebad485fd35db55c8ffbc9497fd6aba34b9 M arch/ia64/kernel/ptrace.c
I:100644 100644 499b7e5317cf4f5ac3564ccf55bfdc5dc2829da5
edd9f07860b227a230ab981d1a8691a68bd01a7a M arch/ia64/kernel/signal.c
Key:
S: Skipped
I: Included Included verbatim
D: Deleted Manually deleted by subsequent user edit
R: Revised Manually revised by subsequent user edit
diff --git a/arch/ia64/kernel/ptrace.c b/arch/ia64/kernel/ptrace.c
--- a/arch/ia64/kernel/ptrace.c
+++ b/arch/ia64/kernel/ptrace.c
@@ -945,6 +945,13 @@ access_uarea (struct task_struct *child,
*data = (pt-cr_ipsr IPSR_MASK);
return 0;
+ case PT_AR_RSC:
+ if (write_access)
+ pt-ar_rsc = *data | (3 2); /* force PL3 */
+ else
+ *data = pt-ar_rsc;
+ return 0;
+
case PT_AR_RNAT:
urbs_end = ia64_get_user_rbs_end(child, pt, NULL);
rnat_addr = (long) ia64_rse_rnat_addr((long *)
@@ -996,9 +1003,6 @@ access_uarea (struct task_struct *child,
case PT_AR_BSPSTORE:
ptr = pt_reg_addr(pt, ar_bspstore);
break;
- case PT_AR_RSC:
- ptr = pt_reg_addr(pt, ar_rsc);
- break;
case PT_AR_UNAT:
ptr = pt_reg_addr(pt, ar_unat);
break;
@@ -1234,7 +1238,7 @@ ptrace_getregs (struct task_struct *chil
static long
ptrace_setregs (struct task_struct *child, struct pt_all_user_regs __user *ppr)
{
- unsigned long psr, ec, lc, rnat, bsp, cfm, nat_bits, val = 0;
+ unsigned long psr, rsc, ec, lc, rnat, bsp, cfm, nat_bits, val = 0;
struct unw_frame_info info;
struct switch_stack *sw;
struct ia64_fpreg fpval;
@@ -1267,7 +1271,7 @@ ptrace_setregs (struct task_struct *chil
/* app regs */
retval |= __get_user(pt-ar_pfs, ppr-ar[PT_AUR_PFS]);
- retval |= __get_user(pt-ar_rsc, ppr-ar[PT_AUR_RSC]);
+ retval |= __get_user(rsc, ppr-ar[PT_AUR_RSC]);
retval |= __get_user(pt-ar_bspstore, ppr-ar[PT_AUR_BSPSTORE]);
retval |= __get_user(pt-ar_unat, ppr-ar[PT_AUR_UNAT]);
retval |= __get_user(pt-ar_ccv, ppr-ar[PT_AUR_CCV]);
@@ -1365,6 +1369,7 @@ ptrace_setregs (struct task_struct *chil
retval |= __get_user(nat_bits, ppr-nat);
retval |= access_uarea(child, PT_CR_IPSR, psr, 1);
+ retval |= access_uarea(child, PT_AR_RSC, rsc, 1);
retval |= access_uarea(child, PT_AR_EC, ec, 1);
retval |= access_uarea(child, PT_AR_LC, lc, 1);
retval |= access_uarea(child, PT_AR_RNAT, rnat, 1);
diff --git a/arch/ia64/kernel/signal.c b/arch/ia64/kernel/signal.c
--- a/arch/ia64/kernel/signal.c
+++ b/arch/ia64/kernel/signal.c
@@ -94,7 +94,7 @@ sys_sigaltstack (const stack_t __user *u
static long
restore_sigcontext (struct sigcontext __user *sc, struct sigscratch *scr)
{
- unsigned long ip, flags, nat, um, cfm;
+ unsigned long ip, flags, nat, um, cfm, rsc;
long err;
/* Always make any pending restarted system calls return -EINTR */
@@ -106,7 +106,7 @@ restore_sigcontext
Re: Preparing the first security update for kernel-source-2.6.8
On Tue, Jun 28, 2005 at 10:36:15PM +0200, Frederik Schueler wrote: Hello, I would like to start preparing a seurity update for kernel-source-2.6.8 in sarge, wich released with version 2.6.8-16. In sarge-security we have an old 2.6.15sarge1 wich never got released. Does anyone object if I update those sources to the revision in sarge, and we start building 2.6.8-16sarge1 from it? I already got some patches from the ubuntu 2.6.8 kernel package addressing the following 5 issues: CAN-2005-0756 CAN-2005-1265 CAN-2005-1762 CAN-2005-1763 CAN-2005-1765 and these 3 still need to be addressed: CAN-2005-1764 CAN-2005-0449 #295949 CAN-2005-0356 #310804 if nobody objects, I would like to commit my changes. Hi, I have been thinking of making some updates too. So far I have just been trolling the 2.6.11.X and 2.6.12.X patch sets. This is primarily intented as a base for rc1 rather than a security update, as almost none of the fixes are security related. I think the best thing to do would be for you to go ahead and start a 2.6.8-16sarge1 in cvs. I will then grab those patches and put them into what I am working on for 2.6.8-17. We also need to think about 2.4.27, but I was planning to do that after 2.6.8 is in the bag. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
