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

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

CAN reference number: CAN-2004-0554

This has been *closed* on 


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:


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


Reply to: