New RedHat Kernel Patch Illegal to Explain to U.S. Users

Russellkhan writes "The Register is running a story about a new RedHat kernel patch that cannot be explained to U.S. citizens or others in the U.S. because of DMCA restrictions. The illegal explanation is hosted at Thefreeworld.net, a site created specifically to deal with these DMCA issues."

Comments

Re:One day...

[flyneye]

uh,dopey,the DCMA came under the CLINTON administration. Perhaps if you actually had a handle on U.S. politics your humor wouldnt just signify your ignorance

This is absolutely silly

[Andy Dodd]

I don't recall the exact wording, but I'm positive the DMCA is intended to cover publishing vulnerabilities about *other people's software* - This is publishing information about THEIR OWN PRODUCT. Seems like someone is overreacting on this one to me.

HERE IT IS!!!! enjoy :-)

[Anonymous Coward]

Security Holes Fixed In Linux 2.4.19

None of the holes documented here are remote. All these problems were
uncovered by auditing and there are no current exploits available. In
the interest of openness and ensuring people are aware of the security
fixes they are documented.

- If the Stradis driver is loaded (hardware must be present) a
maths overflow allowed the user to scribble into kernel memory

- It was possible to feed the SE401 USB hardware driver signed
values and fool kernel checks. This requires the hardware is
present

- The usbvideo driver could be fooled due to a maths overflow corner
case. This requires drivers to be present

- The /proc/slabinfo file could exceed a buffer size and cause
corruption of the kernel. This is really beyond user control but
if it occurs then the user can trigger the corruption

- By setting the TF flag a carefully constructed binary could hang
the kernel dead

- By misusing the rlimit resource limits it was possible to avoid
acct data being written on your process exit

- The joystick driver had erroneous copies in obscure ioctl cases
that could be used to patch the kernel as any user. Hardware
must be present and the module loaded for this vulnerability
to occur

- Multiple errors in the vm86 handling allowed users to force an
"Oops" from the kernel and in some cases to corrupt kernel data.
An additional small fix is needed for 2.4.19 but not 2.4.19-ac
(see bottom)

- The rt_cache_proc file could be tricked into returning chunks of
kernel data.

- On a system with over 1Gb of RAM the loop driver could in some
cases fail and expose kernel data. This is not under user control.
On 2.4.19 the loop driver works fine with large memory systems.

- Multiple /proc files could be persuaded to dump kernel data
due to a sanity checking bug in the proc file handlers

- The XMM SSE registers were not always cleared for new processes
and could expose data from a different task. While it was not
possible to modify another tasks registers there is a small risk
because some cryptographic systems have XMM acceleration functions

We also fixed problems that required privileges to exploit. These affected
the IBM S/390 dasd driver, Openprom on Sparc systems, the Intermezzo file
system, the ewrk3 network driver, module loading, the microcode driver and
vm86. We document these in the interest of completeness.

Finally on a -ac based tree with PnPBIOS enabled a problem existed in some
quite common BIOS implementations that causes a crash when certain 32bit
BIOS calls are made. This allowed users to crash some systems by reading
files in /proc. These files are now root private. The base tree is not
affected as it lacks PnPBIOS support

Credits

The authors would like to thank Silvio Cesare, Stas Sergeev, Andi Kleen,
Alan Cox, Solar Designer, and many others for their work on making 2.4.19 a
more secure kernel.

-- Additional Required Patch --

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.20pre1/arch/i386/kernel/traps.c linux.20pre1-ac1/arch/i386/kernel/traps.c
--- linux.20pre1/arch/i386/kernel/traps.c 2002-08-06 15:40:50.000000000 +0100
+++ linux.20pre1-ac1/arch/i386/kernel/traps.c 2002-08-06 15:42:19.000000000 +0100
@@ -305,8 +319,13 @@
static void inline do_trap(int trapnr, int signr, char *str, int vm86,
struct pt_regs * regs, long error_code, siginfo_t *info)
{
- if (vm86 && regs->eflags & VM_MASK)
- goto vm86_trap;
+ if (regs->eflags & VM_MASK) {
+ if (vm86)
+ goto vm86_trap;
+ else
+ goto trap_signal;
+ }
+
if (!(regs->xcs & 3))
goto kernel_trap;

@@ -514,10 +533,15 @@
{
unsigned int condition;
struct task_struct *tsk = current;
+ unsigned long eip = regs->eip;
siginfo_t info;

__asm__ __volatile__("movl %%db6,%0" : "=r" (condition));

+ /* If the user set TF, it's simplest to clear it right away. */
+ if ((eip >=PAGE_OFFSET) && (regs->eflags & TF_MASK))
+ goto clear_TF;
+
/* Mask out spurious debug traps due to lazy DR7 setting */
if (condition & (DR_TRAP0|DR_TRAP1|DR_TRAP2|DR_TRAP3)) {
if (!tsk->thread.debugreg[7])

Alan Cox works for red-hat.

[leuk_he]

Alan Cox works for red-hat.

Re:Sound familiar?

[Latent IT]

What "international law" requires any country to make a fancy little "declairation of war" when it defends itself (always allowed under the UN Charter) or when it attacks another country?

Your statement is FALSE and you have provided NO SUPPORT for it.

I agree completely. He argues like my wife - just keep saying the same thing over and over again, a little differently.

Dear, is that you?

(--- Please Read!

[Tom7]

I posted late, but I hope my comment won't get lost in all of the noise...