On Thu, Sep 22, 2005 at 05:04:46PM -0300, Marcelo Tosatti wrote:
>
> On Thu, Sep 22, 2005 at 11:30:25AM +0900, Horms wrote:
> > On Wed, Sep 21, 2005 at 01:31:37PM +0300, Nikos Ntarmos wrote:
> > > Package: kernel-source-2.4.27
> > > Version: 2.4.27-11.hls.2005082200
> > > Severity: important
> > > Justification: fails to build from source
> > >
> > > Patch 143_outs.diff.bz2 breaks the kernel compilation on x86_64. The
> > > problem is that it uses the IO_BITMAP_BYTES macro which is defined for
> > > i386 (in linux/include/asm-i386/processor.h) but not for x86_64.
> > > Reverting the patch lets the kernel build again, although I guess the
> > > correct solution would be to add an appropriate IO_BITMAP_BYTES to
> > > linux/include/asm-x86_64/processor.h as well.
> >
> > Hi Nikos,
> >
> > First up, thanks for testing out my prebuild kernels. For the
> > uninitiated they are snapshots of what is in the deabian kernel-team's
> > SVN and live in http://packages.vergenet.net/testing/
> >
> > The problem that you see is a patch that was included in
> > 2.4.27-11 (the current version in sid), though it isn't built
> > for amd64.
> >
> > Could you see if the following patch works for you. I've CCed lkml and
> > Marcelo for their consideration. It seems to me that 2.4 is indeed
> > vulnerable to CAN-2005-0204, perhaps someone can shed some light on
> > this.
> >
> > --
> > Horms
> >
> > Description: [CAN-2005-0204]: AMD64, allows local users to write to privileged IO ports via OUTS instruction
> > Patch author: Suresh Siddha ([email protected])
> > Upstream status: not applied
> > URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146244
> > Patch source: Micah Anderson <[email protected]> (debian-kernel)
> >
> > Added definition of IO_BITMAP_BYTES for Debian's 2.4.27 and
> > submitted upstream for consideration for inclusion in 2.4 -- Horms
>
> And v2.6 does not seem to have been updated either, or a different form of
> the fix has been deployed?
>
> 130 static inline void set_tss_desc(unsigned cpu, void *addr)
> 131 {
> 132 set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned long)addr,
> 133 DESC_TSS,
> 134 sizeof(struct tss_struct) - 1);
> 135 }
Marcelo, This particular vulnerability is not present in 2.6 base. As I
mentioned in that bugzilla, 2.6 base increased IO_BITMAP_BITS to 65536
and the kernel initializes this bitmap pointer during boot appropriately.
But in general the specified limit is wrong and needs to be fixed.
Appended patch will fix the tss limit. Andrew, please apply. Thanks.
--
Fix the x86_64 TSS limit in TSS descriptor.
Signed-off-by: Suresh Siddha <[email protected]>
--- linux-2.6.14-rc1/include/asm-x86_64/desc.h.orig 2005-09-12 20:12:09.000000000 -0700
+++ linux-2.6.14-rc1/include/asm-x86_64/desc.h 2005-09-23 12:50:58.210135128 -0700
@@ -129,7 +129,7 @@ static inline void set_tss_desc(unsigned
{
set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned long)addr,
DESC_TSS,
- sizeof(struct tss_struct) - 1);
+ IO_BITMAP_OFFSET + IO_BITMAP_BYTES + 7);
}
static inline void set_ldt_desc(unsigned cpu, void *addr, int size)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|