Skip to content

L
linux
Switch branch/tag
  1. 24 Apr, 2006 23 commits
  3. 19 Apr, 2006 2 commits
    • Greg Kroah-Hartman's avatar
      Linux 2.6.16.9 · 9d395d19
      Greg Kroah-Hartman authored
      9d395d19
    • Andi Kleen's avatar
      [PATCH] i386/x86-64: Fix x87 information leak between processes (CVE-2006-1056) · 7466f9e7
      Andi Kleen authored 
      AMD K7/K8 CPUs only save/restore the FOP/FIP/FDP x87 registers in FXSAVE
when an exception is pending.  This means the value leak through context
switches and allow processes to observe some x87 instruction state of
other processes.

This was actually documented by AMD, but nobody recognized it as being
different from Intel before.

The fix first adds an optimization: instead of unconditionally calling
FNCLEX after each FXSAVE test if ES is pending and skip it when not
needed. Then do a x87 load from a kernel variable to clear FOP/FIP/FDP.

This means other processes always will only see a constant value defined
by the kernel in their FP state.

I took some pain to make sure to chose a variable that's already in L1
during context switch to make the overhead of this low.

Also alternative() is used to patch away the new code on CPUs who don't
need it.

Patch for both i386/x86-64.

The problem was discovered originally by Jan Beulich. Richard Brunner
provided the basic code for the workarounds, with contribution from Jan.

This is CVE-2006-1056

Cc: richard.brunner@amd.com
Cc: jbeulich@novell.com
Signed-off-by: default avatarAndi Kleen <ak@suse.de>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      7466f9e7
  5. 18 Apr, 2006 2 commits
  7. 17 Apr, 2006 13 commits
    • Greg Kroah-Hartman's avatar
      Linux 2.6.16.7 · 54e5705f
      Greg Kroah-Hartman authored
      54e5705f
    • Hugh Dickins's avatar
      [PATCH] fix MADV_REMOVE vulnerability (CVE-2006-1524 for real this time) · 00ec474c
      Hugh Dickins authored 
      madvise_remove needs to respect file and mmap protections.
Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      00ec474c
    • Greg Kroah-Hartman's avatar
      Linux 2.6.16.6 · 37863c8a
      Greg Kroah-Hartman authored
      37863c8a
    • Hugh Dickins's avatar
      [PATCH] shmat: stop mprotect from giving write permission to a readonly attachment (CVE-2006-1524) · 512dba41
      Hugh Dickins authored 
      I found that all of 2.4 and 2.6 have been letting mprotect give write
permission to a readonly attachment of shared memory, whether or not IPC
would give the caller that permission.

SUS says "The behaviour of this function [mprotect] is unspecified if the
mapping was not established by a call to mmap", but I don't think we can
interpret that as allowing it to subvert IPC permissions.

I haven't tried 2.2, but the 2.2.26 source looks like it gets it right; and
the patch below reproduces that behaviour - mprotect cannot be used to add
write permission to a shared memory segment attached readonly.

This patch is simple, and I'm sure it's what we should have done in 2.4.0:
if you want to go on to switch write permission on and off with mprotect,
just don't attach the segment readonly in the first place.

However, we could have accumulated apps which attach readonly (even though
they would be permitted to attach read/write), and which subsequently use
mprotect to switch write permission on and off: it's not unreasonable.

I was going to add a second ipcperms check in do_shmat, to check for
writable when readonly, and if not writable find_vma and clear VM_MAYWRITE.
 But security_ipc_permission might do auditing, and it seems wrong to
report an attempt for write permission when there has been none.  Or we
could flag the vma as SHM, note the shmid or shp in vm_private_data, and
then get mprotect to check.

But the patch below is a lot simpler: I'd rather stick with it, if we can
convince ourselves somehow that it'll be safe.
Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      512dba41
    • Stephen Hemminger's avatar
      [PATCH] atm: clip causes unregister hang · 23e0ac04
      Stephen Hemminger authored 
      If Classical IP over ATM module is loaded, its neighbor table gets
populated when permanent neighbor entries are created; but these entries
are not flushed when the device is removed. Since the entry never gets
flushed the unregister of the network device never completes.

This version of the patch also adds locking around the reference to
the atm arp daemon to avoid races with events and daemon state changes.
(Note: barrier() was never really safe)

Bug-reference: http://bugzilla.kernel.org/show_bug.cgi?id=6295Signed-off-by: default avatarStephen Hemminger <shemminger@osdl.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      23e0ac04
    • Roland McGrath's avatar
      [PATCH] fix non-leader exec under ptrace · 18b1e819
      Roland McGrath authored 
      This reverts most of commit 30e0fca6.
It broke the case of non-leader MT exec when ptraced.
I think the bug it was intended to fix was already addressed by commit
788e05a6.
Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      18b1e819
    • Paul Fulghum's avatar
      [PATCH] USB: remove __init from usb_console_setup · 49fa79e5
      Paul Fulghum authored 
      This prevents an Oops if booted with "console=ttyUSB0" but without a
USB-serial dongle, and plugged one in afterwards.
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      49fa79e5
    • Pavel Machek's avatar
      [PATCH] Fix suspend with traced tasks · 6b2467e4
      Pavel Machek authored 
      strace /bin/bash misbehaves after resume; this fixes it.

(akpm: it's scary calling refrigerator() in state TASK_TRACED, but it seems to
do the right thing).
Signed-off-by: default avatarPavel Machek <pavel@suse.cz>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6b2467e4
    • Steve French's avatar
      [PATCH] Incorrect signature sent on SMB Read · dea8e11a
      Steve French authored 
      Fixes Samba bug 3621 and kernel.org bug 6147

For servers which require SMB/CIFS packet signing, we were sending the
wrong signature (all zeros) on SMB Read request.  The new cifs routine
to do signatures across an iovec was not complete - and SMB Read, unlike
the new SMBWrite2, did not fall back to the older routine (ie use
SendReceive vs. the more efficient SendReceive2 ie used the older
cifs_sign_smb vs. the disabled  cifs_sign_smb2) for calculating signatures.

This finishes up cifs_sign_smb2/cifs_calc_signature2 so that the callers
of SendReceive2 can get SMB/CIFS packet signatures.

Now that cifs_sign_smb2 is supported, we could start using it in
the write path but this smaller fix does not include the change
to use SMBWrite2 when signatures are required (which when enabled
will make more Writes more efficient and alloc less memory).
Currently Write2 is only used when signatures are not
required at the moment but after more testing we will enable
that as well).

Thanks to James Slepicka and Sam Flory for initial investigation.
Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      dea8e11a
    • Andrew Morton's avatar
      [PATCH] RLIMIT_CPU: fix handling of a zero limit · 284a7c99
      Andrew Morton authored 
      At present the kernel doesn't honour an attempt to set RLIMIT_CPU to zero
seconds.  But the spec says it should, and that's what 2.4.x does.

Fixing this for real would involve some complexity (such as adding a new
it-has-been-set flag to the task_struct, and testing that everwhere, instead
of overloading the value of it_prof_expires).

Given that a 2.4 kernel won't actually send the signal until one second has
expired anyway, let's just handle this case by treating the caller's
zero-seconds as one second.

Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Cliff Wickman <cpw@sgi.com>
Acked-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      284a7c99
    • Nathan Scott's avatar
      [PATCH] Fix utime(2) in the case that no times parameter was passed in. · bc5bd8ac
      Nathan Scott authored 
      SGI-PV: 949858
SGI-Modid: xfs-linux-melb:xfs-kern:25717a
Signed-off-by: default avatarJes Sorensen <jes@sgi.com>
Signed-off-by: default avatarNathan Scott <nathans@sgi.com>
      bc5bd8ac
    • Brian Uhrain says's avatar
      [PATCH] alpha: SMP boot fixes · 3e1792fa
      Brian Uhrain says authored 
      I've encountered two problems with 2.6.16 and newer kernels on my API CS20
(dual 833MHz Alpha 21264b processors).  The first is the kernel OOPSing
because of a NULL pointer dereference while trying to populate SysFS with the
CPU information.  The other is that only one processor was being brought up.
I've included a small Alpha-specific patch that fixes both problems.

The first problem was caused by the CPUs never being properly registered using
register_cpu(), the way it's done on other architectures.

The second problem has to do with the removal of hwrpb_cpu_present_mask in
arch/alpha/kernel/smp.c.  In setup_smp() in the 2.6.15 kernel sources,
hwrpb_cpu_present_mask has a bit set for each processor that is probed, and
afterwards cpu_present_mask is set to the cpumask for the boot CPU.  In the
same function of the same file in the 2.6.16 sources, instead of
hwrpb_cpu_present_mask being set, cpu_possible_map is updated for each probed
CPU.  cpu_present_mask is still set to the cpumask of the boot CPU afterwards.
 The problem lies in include/asm-alpha/smp.h, where cpu_possible_map is
#define'd to be cpu_present_mask.

Cleanups from: Ivan Kokshaysky <ink@jurassic.park.msu.ru>

 - cpu_present_mask and cpu_possible_map are essentially the same thing
   on alpha, as it doesn't support CPU hotplug;
 - allocate "struct cpu" only for present CPUs, like sparc64 does.
   Static array of "struct cpu" is just a waste of memory.
Signed-off-by: default avatarBrian Uhrain <buhrain@rosettastone.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      3e1792fa
    • Mike Miller's avatar
      [PATCH] cciss: bug fix for crash when running hpacucli · d90fd1f7
      Mike Miller authored 
      Fix a crash when running hpacucli with multiple logical volumes on a cciss
controller.  We were not properly initializing the disk->queue and causing
a fault.

Thanks to Hasso Tepper for reporting the problem.  Thanks to Steve Cameron
for root causing the problem.  Most of the patch just moves things around.
The fix is a one-liner.
Signed-off-by: default avatarMike Miller <mike.miller@hp.com>
Signed-off-by: default avatarStephen Cameron <steve.cameron@hp.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d90fd1f7
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7