[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.
> 
> 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.

I am currently looking into CAN-2005-1913,
which at a glance does not seem to affect 2.6.8.
For referance, the patch from 2.6.12.a is as follows.

-- 
Horms


commit fe3d5c8793fcaf33c5d3118a7f3ffc135eadaf4d
tree 19fac0a8a24b4c106babdfee1e68b5e794ece216
parent 9ee1c939d1cb936b1f98e8d81aeffab57bae46ab
author Linus Torvalds <torvalds@osdl.org> 1119125869 -0700
committer Chris Wright <chrisw@osdl.org> 1119468770 -0700

[PATCH] Clean up subthread exec (CAN-2005-1913)

Make sure we re-parent itimers.  If subthread exec's with timer pending,
signal is delivered to old group-leader and can panic kernel.

Signed-off-by: Linus Torvalds <torvalds@ppc970.osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>

I:100644 100644 e56ee24370255e2ab4df9a3933ec03f0d07a2de3 422cc0ec5e366b846336a22398ddc019ca6212c2 M	fs/exec.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/fs/exec.c b/fs/exec.c
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -649,6 +649,7 @@ static inline int de_thread(struct task_
 	}
 	sig->group_exit_task = NULL;
 	sig->notify_count = 0;
+	sig->real_timer.data = (unsigned long)current;
 	spin_unlock_irq(lock);
 
 	/*



Reply to: