Posted Dec 2, 2003 21:47 UTC (Tue) by alan (subscriber, #4018)
[Link]
2.2 and 2.4 are so different, it likely wouldn't have mattered anyway
How far back?
Posted Dec 3, 2003 0:15 UTC (Wed) by pblanco (guest, #16087)
[Link]
It's interesting that my SuSE 9.0 with the 2.4.21-144 kernel has the patch. The article implied that 2.4.22 and 2.4.23 had the patch, so I assumed that earlier releases wouldn't have it. What gives?
How far back?
Posted Dec 3, 2003 3:17 UTC (Wed) by Mithrandir (subscriber, #3031)
[Link]
SuSE have applied 144 patches to that kernel, so it could hardly be called a vanilla 2.4.21. I'd be guessing that they applied the patch as a routine security patch at the time that it was released for 2.4.23-pre.
How far back?
Posted Dec 11, 2003 6:59 UTC (Thu) by wildpossum (guest, #17744)
[Link]
No that is not implied. What SUSE (and other vendors) do is patch the kernel that was released with that box version, rather than risk breaking things by upping the kernel version without adequate testing. So the bug was in the 9.0's 2.4.21 kernel, SUSE patched it when the alarm went out, and you got this update when you ran the YaST Online Update tool.
How far back?
Posted Dec 4, 2003 12:07 UTC (Thu) by IkeTo (subscriber, #2122)
[Link]
2.2 does not have the special case code for brk(), i.e., do_brk, which tries to speed things up because the end of the text segment is special. In 2.2, do_mmap is used to do brk, and do_mmap do all the checking. I think the kernel developers forget that the ELF-header can be modified to start the program such that the text segment might be at the end of the memory space, so they think that it is not possible to have brk() called in such a way that can extend through the end of the address space---normally, the virtual memory bound checking will stop anything wrong from happening.