Bug#266882: CAN-2004-0554 i387.h in kernel: asm volatile("fnclex ; fwait");
Package: kernel-source-2.4.18
Version: 2.4.18-14.3
Severity: important
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux adjani 2.4.18 #1 Fri Aug 6 14:11:00 CEST 2004 i686
Locale: LANG=pl_PL.ISO-8859-2, LC_CTYPE=pl_PL.ISO-8859-2
Versions of packages kernel-source-2.4.18 depends on:
ii binutils 2.12.90.0.1-4 The GNU assembler, linker and bina
ii bzip2 1.0.2-1 A high-quality block-sorting file
ii fileutils 4.1-10 GNU file management utilities
This is a known bug from 11 June 2004, with a known solution.
The claim is that the bug - run by an ordinary unprivileged user -
crashes systems running kernels 2.4.* and 2.6.* running on 386
systems. i personally have not tested this; i only tested the exploit
after compiling in the patch.
The main web page seems to be:
http://linuxreviews.org/news/2004/06/11_kernel_crash/
CAN reference number: CAN-2004-0554
This has been *closed* on
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262540
but it affects 2.4.18 which is part of the stable distribution,
so AFAIK the bug should remain *open* for 2.4.18 source and image
packages until 2.4.18 is fixed and distributed on security.debian.org
as usual.
On 3 different computers using hand-compiled version of
Package: kernel-source-2.4.18
Version: 2.4.18-14.3
i have found that the official, Linus-recommended ;) patch works
fine. It doesn't stop the exploit from running and using as much CPU
as possible (i get output ".........." nonstop to my rxvt-xterm), but
it does prevent the exploit from crashing the system. The job is then
easily killed by the ordinary user.
All that is needed is to add "fnclex;" to i387.h :
#define clear_fpu( tsk ) do { \
if ( tsk->flags & PF_USEDFPU ) { \
asm volatile("fnclex ; fwait"); \
tsk->flags &= ~PF_USEDFPU; \
stts(); \
More formally, the patch is here:
http://linuxreviews.org/news/2004/06/11_kernel_crash/24_kernel_ia32-and-x86_64-fix-fpu-state.patch.txt
IMHO we need to go to 2.4.18-14.4
Debian seems to be the only major distribution not to have corrected
this - it's corrected in 2.4.26 (it seems), but not in 2.4.18 which is
supposed to be highly secure...
cheers
boud
Reply to: