Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Oct 12, 2007
  1. Linux 2.6.16.55

    Adrian Bunk authored
  2. Revert "TCP: Fix TCP handling of SACK in bidirectional flows"

    Adrian Bunk authored
    This reverts commit 3198d0f.
Commits on Oct 7, 2007
  1. Linux 2.6.16.55-rc1

    Adrian Bunk authored
  2. @tiwai

    Convert snd-page-alloc proc file to use seq_file (CVE-2007-4571)

    tiwai authored Adrian Bunk committed
    Commit ccec6e2 in mainline.
    
    Use seq_file for the proc file read/write of snd-page-alloc module.
    This automatically fixes bugs in the old proc code.
    
    Adrian Bunk:
    Backported to 2.6.16.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
Commits on Oct 6, 2007
  1. snd_mem_proc_read(): convert to list_for_each_entry*

    Adrian Bunk authored
    Stolen from a patch by Johannes Berg <johannes@sipsolutions.net>.
    
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  2. sysfs: store sysfs inode nrs in s_ino to avoid readdir oopses (CVE-20…

    Eric Sandeen authored Adrian Bunk committed
    …07-3104)
    
    Backport of
    ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/broken-out/gregkh-driver-sysfs-allocate-inode-number-using-ida.patch
    
    For regular files in sysfs, sysfs_readdir wants to traverse
    sysfs_dirent->s_dentry->d_inode->i_ino to get to the inode number.
    But, the dentry can be reclaimed under memory pressure, and there is
    no synchronization with readdir.  This patch follows Tejun's scheme of
    allocating and storing an inode number in the new s_ino member of a
    sysfs_dirent, when dirents are created, and retrieving it from there
    for readdir, so that the pointer chain doesn't have to be traversed.
    
    Tejun's upstream patch uses a new-ish "ida" allocator which brings
    along some extra complexity; this -stable patch has a brain-dead
    incrementing counter which does not guarantee uniqueness, but because
    sysfs doesn't hash inodes as iunique expects, uniqueness wasn't
    guaranteed today anyway.
    
    Adrian Bunk:
    Backported to 2.6.16.
    
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  3. random: fix bound check ordering (CVE-2007-3105)

    Matt Mackall authored Adrian Bunk committed
    If root raised the default wakeup threshold over the size of the
    output pool, the pool transfer function could overflow the stack with
    RNG bytes, causing a DoS or potential privilege escalation.
    
    (Bug reported by the PaX Team <pageexec@freemail.hu>)
    
    Signed-off-by: Matt Mackall <mpm@selenic.com>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  4. random: fix seeding with zero entropy (CVE-2007-2453 2 of 2)

    Matt Mackall authored Adrian Bunk committed
    Add data from zero-entropy random_writes directly to output pools to
    avoid accounting difficulties on machines without entropy sources.
    
    Tested on lguest with all entropy sources disabled.
    
    Signed-off-by: Matt Mackall <mpm@selenic.com>
    Acked-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  5. random: fix error in entropy extraction (CVE-2007-2453 1 of 2)

    Matt Mackall authored Adrian Bunk committed
    Fix cast error in entropy extraction.
    Add comments explaining the magic 16.
    Remove extra confusing loop variable.
    
    Signed-off-by: Matt Mackall <mpm@selenic.com>
    Acked-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  6. @holtmann

    Reset current->pdeath_signal on SUID binary execution (CVE-2007-3848)

    holtmann authored Adrian Bunk committed
    This fixes a vulnerability in the "parent process death signal"
    implementation discoverd by Wojciech Purczynski of COSEINC PTE Ltd.
    and iSEC Security Research.
    
    http://marc.info/?l=bugtraq&m=118711306802632&w=2
    
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  7. fix buffer overflow in the moxa driver (CVE-2005-0504)

    Dann Frazier authored Adrian Bunk committed
    Signed-off-by: Dann Frazier <dannf@hp.com>
    Signed-off-by: Andres Salomon <dilinger@debian.org>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  8. @kumargala

    [POWERPC] Flush registers to proper task context

    kumargala authored Adrian Bunk committed
    When we flush register state for FP, Altivec, or SPE in flush_*_to_thread
    we need to respect the task_struct that the caller has passed to us.
    
    Most cases we are called with current, however sometimes (ptrace) we may
    be passed a different task_struct.
    
    This showed up when using gdbserver debugging a simple program that used
    floating point. When gdb tried to show the FP regs they all showed up as 0,
    because the child's FP registers were never properly flushed to memory.
    
    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  9. x86_64: Zero extend all registers after ptrace in 32bit entry path (C…

    Andi Kleen authored Adrian Bunk committed
    …VE-2007-4573)
    
    Strictly it's only needed for eax.
    
    It actually does a little more than strictly needed -- the other registers
    are already zero extended.
    
    Also remove the now unnecessary and non functional compat task check
    in ptrace.
    
    Found by Wojciech Purczynski
    
    Signed-off-by: Andi Kleen <ak@suse.de>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  10. unexport ip_conntrack_{,un}register_notifier

    Adrian Bunk authored
    Static functions mustn't be exported.
    
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  11. sound/core/pcm_lib.c: don't export static functions

    Adrian Bunk authored
    Static functions mustn't be exported.
    
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  12. unexport csr1212_release_keyval

    Adrian Bunk authored
    A static function mustn't be exported.
    
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  13. unexport cpufreq_parse_governor

    Adrian Bunk authored
    A static function mustn't be exported.
    
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  14. @AdrianBunk

    unexport neigh_update_hhs

    Adrian Bunk authored AdrianBunk committed
    A static function mustn't be exported.
    
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  15. @AdrianBunk

    [SPARC]: fix sparc64 gcc 4.2 compile failure

    Mikael Pettersson authored AdrianBunk committed
    Compiling 2.6.21-rc5 with gcc-4.2.0 20070317 (prerelease)
    for sparc64 fails as follows:
    
      gcc -Wp,-MD,arch/sparc64/kernel/.time.o.d  -nostdinc -isystem /home/mikpe/pkgs/linux-sparc64/gcc-4.2.0/lib/gcc/sparc64-unknown-linux-gnu/4.2.0/include -D__KERNEL__ -Iinclude  -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs -fomit-frame-pointer  -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -Werror   -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(time)"  -D"KBUILD_MODNAME=KBUILD_STR(time)" -c -o arch/sparc64/kernel/time.o arch/sparc64/kernel/time.c
    cc1: warnings being treated as errors
    arch/sparc64/kernel/time.c: In function 'kick_start_clock':
    arch/sparc64/kernel/time.c:559: warning: overflow in implicit constant conversion
    make[1]: *** [arch/sparc64/kernel/time.o] Error 1
    make: *** [arch/sparc64/kernel] Error 2
    
    gcc gets unhappy when the MSTK_SET macro's u8 __val variable
    is updated with &= ~0xff (MSTK_YEAR_MASK). Making the constant
    unsigned fixes the problem.
    
    [ I fixed up the sparc32 side as well -DaveM ]
    
    Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  16. @AdrianBunk

    unexport ktime_get_real

    Adrian Bunk authored AdrianBunk committed
    A static function mustn't be exported.
    
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  17. @AdrianBunk

    [IPSEC] AH4: Update IPv4 options handling to conform to RFC 4302.

    Nick Bowler authored AdrianBunk committed
    In testing our ESP/AH offload hardware, I discovered an issue with how
    AH handles mutable fields in IPv4.  RFC 4302 (AH) states the following
    on the subject:
    
            For IPv4, the entire option is viewed as a unit; so even
            though the type and length fields within most options are immutable
            in transit, if an option is classified as mutable, the entire option
            is zeroed for ICV computation purposes.
    
    The current implementation does not zero the type and length fields,
    resulting in authentication failures when communicating with hosts
    that do (i.e. FreeBSD).
    
    I have tested record route and timestamp options (ping -R and ping -T)
    on a small network involving Windows XP, FreeBSD 6.2, and Linux hosts,
    with one router.  In the presence of these options, the FreeBSD and
    Linux hosts (with the patch or with the hardware) can communicate.
    The Windows XP host simply fails to accept these packets with or
    without the patch.
    
    I have also been trying to test source routing options (using
    traceroute -g), but haven't had much luck getting this option to work
    *without* AH, let alone with.
    
    Signed-off-by: Nick Bowler <nbowler@ellipticsemi.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
Commits on Sep 24, 2007
  1. @AdrianBunk

    Linux 2.6.16.54

    AdrianBunk authored
  2. @AdrianBunk

    Linux 2.6.16.54-rc1

    AdrianBunk authored
  3. @AdrianBunk

    TCP: Fix TCP handling of SACK in bidirectional flows

    Ilpo Järvinen authored AdrianBunk committed
    It's possible that new SACK blocks that should trigger new LOST
    markings arrive with new data (which previously made is_dupack
    false). In addition, I think this fixes a case where we get
    a cumulative ACK with enough SACK blocks to trigger the fast
    recovery (is_dupack would be false there too).
    
    I'm not completely pleased with this solution because readability
    of the code is somewhat questionable as 'is_dupack' in SACK case
    is no longer about dupacks only but would mean something like
    'lost_marker_work_todo' too... But because of Eifel stuff done
    in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to
    the if statement which seems attractive solution. Nevertheless,
    I didn't like adding another variable just for that either... :-)
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  4. @digitalentity @AdrianBunk

    [PPP]: Fix output buffer size in ppp_decompress_frame().

    digitalentity authored AdrianBunk committed
    This patch addresses the issue with "osize too small" errors in mppe
    encryption.  The patch fixes the issue with wrong output buffer size
    being passed to ppp decompression routine.
    
    --------------------
    As pointed out by Suresh Mahalingam, the issue addressed by
    ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet.
    The size of allocated output buffer is correct, however it size passed to
    ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that.
    --------------------
    
    Signed-off-by: Konstantin Sharlaimov <konstantin.sharlaimov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  5. @digitalentity @AdrianBunk

    [PPP]: Fix osize too small errors when decoding mppe.

    digitalentity authored AdrianBunk committed
    The mppe_decompress() function required a buffer that is 1 byte too
    small when receiving a message of mru size. This fixes buffer
    allocation to prevent this from occurring.
    
    Signed-off-by: Konstantin Sharlaimov <konstantin.sharlaimov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
Commits on Aug 30, 2007
  1. @davem330 @AdrianBunk

    [MATH-EMU]: Fix underflow exception reporting.

    davem330 authored AdrianBunk committed
    The underflow exception cases were wrong.
    
    This is one weird area of ieee1754 handling in that the underflow
    behavior changes based upon whether underflow is enabled in the trap
    enable mask of the FPU control register.  As a specific case the Sparc
    V9 manual gives us the following description:
    
    --------------------
    If UFM = 0:     Underflow occurs if a nonzero result is tiny and a
                    loss of accuracy occurs.  Tininess may be detected
                    before or after rounding.  Loss of accuracy may be
                    either a denormalization loss or an inexact result.
    
    If UFM = 1:     Underflow occurs if a nonzero result is tiny.
                    Tininess may be detected before or after rounding.
    --------------------
    
    What this amounts to in the packing case is if we go subnormal,
    we set underflow if any of the following are true:
    
    1) rounding sets inexact
    2) we ended up rounding back up to normal (this is the case where
       we set the exponent to 1 and set the fraction to zero), this
       should set inexact too
    3) underflow is set in FPU control register trap-enable mask
    
    The initially discovered example was "DBL_MIN / 16.0" which
    incorrectly generated an underflow.  It should not, unless underflow
    is set in the trap-enable mask of the FPU csr.
    
    Another example, "0x0.0000000000001p-1022 / 16.0", should signal both
    inexact and underflow.  The cpu implementations and ieee1754
    literature is very clear about this.  This is case #2 above.
    
    However, if underflow is set in the trap enable mask, only underflow
    should be set and reported as a trap.  That is handled properly by the
    prioritization logic in
    
    arch/sparc{,64}/math-emu/math.c:record_exception().
    
    Based upon a report and test case from Jakub Jelinek.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  2. @AdrianBunk

    [SPARC32]: Fix rounding errors in ndelay/udelay implementation.

    Mark Fortescue authored AdrianBunk committed
    __ndelay and __udelay have not been delayung >= specified time.
    The problem with __ndelay has been tacked down to the rounding of the
    multiplier constant. By changing this, delays > app 18us are correctly
    calculated.
    The problem with __udelay has also been tracked down to rounding issues.
    Changing the multiplier constant (to match that used in sparc64) corrects
    for large delays and adding in a rounding constant corrects for trunctaion
    errors in the claculations.
    Many short delays will return without looping. This is not an error as there
    is the fixed delay of doing all the maths to calculate the loop count.
    
    Signed-off-by: Mark Fortescue <mark@mtfhpc.demon.co.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  3. @AdrianBunk

    [SPARC32]: Fix bug in sparc optimized memset.

    Alexander Shmelev authored AdrianBunk committed
    Sparc optimized memset (arch/sparc/lib/memset.S) does not fill last
    byte of the memory area, if area size is less than 8 bytes and start
    address is not word (4-bytes) aligned.
    
    Here is code chunk where bug located:
    /* %o0 - memory address, %o1 - size, %g3 - value */
    8:
         add    %o0, 1, %o0
        subcc    %o1, 1, %o1
        bne,a    8b
         stb %g3, [%o0 - 1]
    
    This code should write byte every loop iteration, but last time delay
    instruction stb is not executed because branch instruction sets
    "annul" bit.
    
    Patch replaces bne,a by bne instruction.
    
    Error can be reproduced by simple kernel module:
    
    --------------------
    #include <linux/module.h>
    #include <linux/config.h>
    #include <linux/kernel.h>
    #include <linux/errno.h>
    #include <string.h>
    
    static void do_memset(void **p, int size)
    {
            memset(p, 0x00, size);
    }
    
    static int __init memset_test_init(void)
    {
        char fooc[8];
        int *fooi;
        memset(fooc, 0xba, sizeof(fooc));
    
        do_memset((void**)(fooc + 3), 1);
    
        fooi = (int*) fooc;
        printk("%08X %08X\n", fooi[0], fooi[1]);
    
        return -1;
    }
    
    static void __exit memset_test_cleanup(void)
    {
        return;
    }
    
    module_init(memset_test_init);
    module_exit(memset_test_cleanup);
    
    MODULE_LICENSE("GPL");
    EXPORT_NO_SYMBOLS;
    --------------------
    
    Signed-off-by: Alexander Shmelev <ashmelev@task.sun.mcst.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
Commits on Aug 23, 2007
  1. @neilbrown @AdrianBunk

    md: avoid possible BUG_ON in md bitmap handling

    neilbrown authored AdrianBunk committed
    md/bitmap tracks how many active write requests are pending on blocks
    associated with each bit in the bitmap, so that it knows when it can clear
    the bit (when count hits zero).
    
    The counter has 14 bits of space, so if there are ever more than 16383, we
    cannot cope.
    
    Currently the code just calles BUG_ON as "all" drivers have request queue
    limits much smaller than this.
    
    However is seems that some don't.  Apparently some multipath configurations
    can allow more than 16383 concurrent write requests.
    
    So, in this unlikely situation, instead of calling BUG_ON we now wait
    for the count to drop down a bit.  This requires a new wait_queue_head,
    some waiting code, and a wakeup call.
    
    Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower
    in that case...).
    
    Signed-off-by: Neil Brown <neilb@suse.de>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
Commits on Aug 22, 2007
  1. @neilbrown @AdrianBunk

    md: fix a few problems with the interface (sysfs and ioctl) to md

    neilbrown authored AdrianBunk committed
    While developing more functionality in mdadm I found some bugs in md...
    
    - When we remove a device from an inactive array (write 'remove' to
      the 'state' sysfs file - see 'state_store') would should not
      update the superblock information - as we may not have
      read and processed it all properly yet.
    
    - initialise all raid_disk entries to '-1' else the 'slot sysfs file
      will claim '0' for all devices in an array before the array is
      started.
    
    - all '\n' not to be present at the end of words written to
      sysfs files
    
    - when we use SET_ARRAY_INFO to set the md metadata version,
      set the flag to say that there is persistant metadata.
    
    - allow GET_BITMAP_FILE to be called on an array that hasn't
      been started yet.
    
    Signed-off-by: Neil Brown <neilb@suse.de>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  2. @neilbrown @AdrianBunk

    md: assorted md and raid1 one-liners

    neilbrown authored AdrianBunk committed
    Fix few bugs that meant that:
      - superblocks weren't alway written at exactly the right time (this
        could show up if the array was not written to - writting to the array
        causes lots of superblock updates and so hides these errors).
    
      - restarting device recovery after a clean shutdown (version-1 metadata
        only) didn't work as intended (or at all).
    
    1/ Ensure superblock is updated when a new device is added.
    2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync.
       The body of this if takes one of two branches depending on whether
       MD_RECOVERY_SYNC is set, so testing it in the clause of the if
       is wrong.
    3/ Flag superblock for updating after a resync/recovery finishes.
    4/ If we find the neeed to restart a recovery in the middle (version-1
       metadata only) make sure a full recovery (not just as guided by
       bitmaps) does get done.
    
    Signed-off-by: Neil Brown <neilb@suse.de>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  3. @neilbrown @AdrianBunk

    md: allow SET_BITMAP_FILE to work on 64bit kernel with 32bit userspace

    neilbrown authored AdrianBunk committed
    ..  so that you can use bitmaps with 32bit userspace on a 64 bit kernel.
    
    Signed-off-by: Neil Brown <neilb@suse.de>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  4. @neilbrown @AdrianBunk

    md: fix some small races in bitmap plugging in raid5

    neilbrown authored AdrianBunk committed
    The comment gives more details, but I didn't quite have the sequencing write,
    so there was room for races to leave bits unset in the on-disk bitmap for
    short periods of time.
    
    Signed-off-by: Neil Brown <neilb@suse.de>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
  5. @neilbrown @AdrianBunk

    md: fix a plug/unplug race in raid5

    neilbrown authored AdrianBunk committed
    When a device is unplugged, requests are moved from one or two (depending on
    whether a bitmap is in use) queues to the main request queue.
    
    So whenever requests are put on either of those queues, we should make sure
    the raid5 array is 'plugged'.  However we don't.  We currently plug the raid5
    queue just before putting requests on queues, so there is room for a race.  If
    something unplugs the queue at just the wrong time, requests will be left on
    the queue and nothing will want to unplug them.  Normally something else will
    plug and unplug the queue fairly soon, but there is a risk that nothing will.
    
    Signed-off-by: Neil Brown <neilb@suse.de>
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
Something went wrong with that request. Please try again.