Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Jan 14, 2008
  1. @gregkh

    Linux 2.6.22.16

    gregkh authored
  2. @gregkh

    Use access mode instead of open flags to determine needed permissions…

    Linus Torvalds authored gregkh committed
    … (CVE-2008-0001)
    
    patch 974a9f0 in mainline
    
    Way back when (in commit 834f2a4, aka
    "VFS: Allow the filesystem to return a full file pointer on open intent"
    to be exact), Trond changed the open logic to keep track of the original
    flags to a file open, in order to pass down the the intent of a dentry
    lookup to the low-level filesystem.
    
    However, when doing that reorganization, it changed the meaning of
    namei_flags, and thus inadvertently changed the test of access mode for
    directories (and RO filesystem) to use the wrong flag.  So fix those
    test back to use access mode ("acc_mode") rather than the open flag
    ("flag").
    
    Issue noticed by Bill Roman at Datalight.
    
    Reported-and-tested-by: Bill Roman <bill.roman@datalight.com>
    Acked-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commits on Dec 14, 2007
  1. @gregkh

    Linux 2.6.22.15

    gregkh authored
  2. @xemul @gregkh

    BRIDGE: Properly dereference the br_should_route_hook

    xemul authored gregkh committed
    [BRIDGE]: Properly dereference the br_should_route_hook
    
    [ Upstream commit: 82de382 ]
    
    This hook is protected with the RCU, so simple
    
    if (br_should_route_hook)
    	br_should_route_hook(...)
    
    is not enough on some architectures.
    
    Use the rcu_dereference/rcu_assign_pointer in this case.
    
    Fixed Stephen's comment concerning using the typeof().
    
    Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @htejun @gregkh

    libata: kill spurious NCQ completion detection

    htejun authored gregkh committed
    patch 459ad68 in mainline.
    
    Spurious NCQ completion detection implemented in ahci was incorrect.
    On AHCI receving and processing FISes and raising interrupts are not
    interlocked and spurious interrupts are expected.
    
    For example, if an interrupt occurs while interrupt handler is running
    and the running interrupt handler handles the event the new IRQ
    indicated, after IRQ handler finishes, it will be executed again
    because IRQ pending bit is set by the new interrupt but there won't be
    anything to process.
    
    Please read the following message for more information.
    
      http://article.gmane.org/gmane.linux.ide/26012
    
    This patch...
    
    * Removes all spurious IRQ whining from ahci.  Spurious NCQ completion
      detection was completely wrong.  Spurious D2H Register FIS taught us
      that some early drives send spurious D2H Register FIS with I bit set
      while NCQ commands are in progress but none of recent drives does
      that and even the ones which show such behavior can do NCQ fine.
    
    * Kills all NCQ blacklist entries which were added because of spurious
      NCQ completions.  I tracked down each commit and verified all
      removed ones are actually added because of spurious completions.
    
      WD740ADFD-00NLR1 wasn't deleted but moved upward because the drive
      not only had spurious NCQ completions but also is slow on sequential
      data transfers if NCQ is enabled.
    
      Maxtor 7V300F0 was added by 0e3dbc0
      from Alan Cox.  I can only find evidences that the drive only had
      troubles with spuruious completions by searching the mailing list.
      This entry needs to be verified and removed if it doesn't have other
      NCQ related problems.
    
    Signed-off-by: Tejun Heo <htejun@gmail.com>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Signed-off-by: Jeff Garzik <jeff@garzik.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @kaber @gregkh

    NETFILTER: xt_TCPMSS: remove network triggerable WARN_ON

    kaber authored gregkh committed
    [NETFILTER]: xt_TCPMSS: remove network triggerable WARN_ON
    
    [ Upstream commit: 9dc0564 ]
    
    ipv6_skip_exthdr() returns -1 for invalid packets. don't WARN_ON
    that.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @kaber @gregkh

    XFRM: Fix leak of expired xfrm_states

    kaber authored gregkh committed
    [XFRM]: Fix leak of expired xfrm_states
    
    [ Upstream commit: 5dba479 ]
    
    The xfrm_timer calls __xfrm_state_delete, which drops the final reference
    manually without triggering destruction of the state. Change it to use
    xfrm_state_put to add the state to the gc list when we're dropping the
    last reference. The timer function may still continue to use the state
    safely since the final destruction does a del_timer_sync().
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    Revert "Fix SMP poweroff hangs"

    gregkh authored
    This reverts the following changeset in 2.6.22.10 that caused a lot of
    reported problems.
    
    	From: Mark Lord <lkml@rtr.ca>
    
    	commit 4047727 from upstream
    
    	We need to disable all CPUs other than the boot CPU (usually 0) before
    	attempting to power-off modern SMP machines.  This fixes the
    	hang-on-poweroff issue on my MythTV SMP box, and also on Thomas Gleixner's
    	new toybox.
    
    	Signed-off-by: Mark Lord <mlord@pobox.com>
    	Acked-by: Thomas Gleixner <tglx@linutronix.de>
    	Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
    	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    	Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    	Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    There still is a remaining shutdown problem in 2.6.22 with old APM based
    systems, but this fix is not the correct one
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @neilbrown @gregkh

    knfsd: Validate filehandle type in fsid_source

    neilbrown authored gregkh committed
    patch b8da0d1 in mainline.
    
    fsid_source decided where to get the 'fsid' number to
    return for a GETATTR based on the type of filehandle.
    It can be from the device, from the fsid, or from the
    UUID.
    
    It is possible for the filehandle to be inconsistent
    with the export information, so make sure the export information
    actually has the info implied by the value returned by
    fsid_source.
    
    Signed-off-by: Neil Brown <neilb@suse.de>
    Cc: "Luiz Fernando N. Capitulino" <lcapitulino@gmail.com>
    Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Oliver Pintr <oliver.pntr@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @xemul @gregkh

    BRIDGE: Lost call to br_fdb_fini() in br_init() error path

    xemul authored gregkh committed
    [BRIDGE]: Lost call to br_fdb_fini() in br_init() error path
    
    [ Upstream commit: 17efdd4 ]
     
    In case the br_netfilter_init() (or any subsequent call)
    fails, the br_fdb_fini() must be called to free the allocated
    in br_fdb_init() br_fdb_cache kmem cache.
    
    Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @xemul @gregkh

    DECNET: dn_nl_deladdr() almost always returns no error

    xemul authored gregkh committed
    [DECNET]: dn_nl_deladdr() almost always returns no error
    
    [ Upstream commit: 3ccd862 ]
    
    As far as I see from the err variable initialization
    the dn_nl_deladdr() routine was designed to report errors
    like "EADDRNOTAVAIL" and probaby "ENODEV".
    
    But the code sets this err to 0 after the first nlmsg_parse
    and goes on, returning this 0 in any case.
    
    Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
    Acked-by: Steven Whitehouse <swhiteho@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    IPV6: Restore IPv6 when MTU is big enough

    Evgeniy Polyakov authored gregkh committed
    [IPV6]: Restore IPv6 when MTU is big enough
    
    [ Upstream commit: d31c7b8 ]
    
    Avaid provided test application, so bug got fixed.
    
    IPv6 addrconf removes ipv6 inner device from netdev each time cmu
    changes and new value is less than IPV6_MIN_MTU (1280 bytes).
    When mtu is changed and new value is greater than IPV6_MIN_MTU,
    it does not add ipv6 addresses and inner device bac.
    
    This patch fixes that.
    
    Tested with Avaid's application, which works ok now.
    
    Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    RXRPC: Add missing select on CRYPTO

    David Howells authored gregkh committed
    [RXRPC]: Add missing select on CRYPTO
    
    [ Upstream commit: d5a784b ]
    
    AF_RXRPC uses the crypto services, so should depend on or select CRYPTO.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    TCP: illinois: Incorrect beta usage

    Stephen Hemminger authored gregkh committed
    [TCP] illinois: Incorrect beta usage
    
    [ Upstream commit: a357dde ]
    
    Lachlan Andrew observed that my TCP-Illinois implementation uses the
    beta value incorrectly:
    The parameter  beta  in the paper specifies the amount to decrease
    *by*:  that is, on loss,
     W <-  W -  beta*W
    but in   tcp_illinois_ssthresh() uses  beta  as the amount
    to decrease  *to*: W <- beta*W
    
    This bug makes the Linux TCP-Illinois get less-aggressive on uncongested network,
    hurting performance. Note: since the base beta value is .5, it has no
    impact on a congested network.
    
    Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @gregkh

    TEXTSEARCH: Do not allow zero length patterns in the textsearch infra…

    Pablo Neira Ayuso authored gregkh committed
    …structure
    
    [TEXTSEARCH]: Do not allow zero length patterns in the textsearch infrastructure
    
    [ Upstream commit: e03ba84 ]
    
    If a zero length pattern is passed then return EINVAL.
    Avoids infinite loops (bm) or invalid memory accesses (kmp).
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @gregkh

    UNIX: EOF on non-blocking SOCK_SEQPACKET

    Florian Zumbiehl authored gregkh committed
    [UNIX]: EOF on non-blocking SOCK_SEQPACKET
    
    [ Upstream commit: 0a11225 ]
    
    I am not absolutely sure whether this actually is a bug (as in: I've got
    no clue what the standards say or what other implementations do), but at
    least I was pretty surprised when I noticed that a recv() on a
    non-blocking unix domain socket of type SOCK_SEQPACKET (which is connection
    oriented, after all) where the remote end has closed the connection
    returned -1 (EAGAIN) rather than 0 to indicate end of file.
    
    This is a test case:
    
    | #include <sys/types.h>
    | #include <unistd.h>
    | #include <sys/socket.h>
    | #include <sys/un.h>
    | #include <fcntl.h>
    | #include <string.h>
    | #include <stdlib.h>
    |
    | int main(){
    | 	int sock;
    | 	struct sockaddr_un addr;
    | 	char buf[4096];
    | 	int pfds[2];
    |
    | 	pipe(pfds);
    | 	sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
    | 	addr.sun_family=AF_UNIX;
    | 	strcpy(addr.sun_path,"/tmp/foobar_testsock");
    | 	bind(sock,(struct sockaddr *)&addr,sizeof(addr));
    | 	listen(sock,1);
    | 	if(fork()){
    | 		close(sock);
    | 		sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
    | 		connect(sock,(struct sockaddr *)&addr,sizeof(addr));
    | 		fcntl(sock,F_SETFL,fcntl(sock,F_GETFL)|O_NONBLOCK);
    | 		close(pfds[1]);
    | 		read(pfds[0],buf,sizeof(buf));
    | 		recv(sock,buf,sizeof(buf),0); // <-- this one
    | 	}else accept(sock,NULL,NULL);
    | 	exit(0);
    | }
    
    If you try it, make sure /tmp/foobar_testsock doesn't exist.
    
    The marked recv() returns -1 (EAGAIN) on 2.6.23.9. Below you find a
    patch that fixes that.
    
    Signed-off-by: Florian Zumbiehl <florz@florz.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @gregkh

    ATM: [he] initialize lock and tasklet earlier

    chas williams authored gregkh committed
    [ATM]: [he] initialize lock and tasklet earlier
    
    [ Upstream commit: 8a8037a ]
    
    if you are lucky (unlucky?) enough to have shared interrupts, the
    interrupt handler can be called before the tasklet and lock are ready
    for use.
    
    Signed-off-by: chas williams <chas@cmf.nrl.navy.mil>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @herbertx @gregkh

    CRYPTO api: Fix potential race in crypto_remove_spawn

    herbertx authored gregkh committed
    [CRYPTO] api: Fix potential race in crypto_remove_spawn
    
    [ Upstream commit: 38cb241 ]
    
    As it is crypto_remove_spawn may try to unregister an instance which is
    yet to be registered.  This patch fixes this by checking whether the
    instance has been registered before attempting to remove it.
    
    It also removes a bogus cra_destroy check in crypto_register_instance as
    1) it's outside the mutex;
    2) we have a check in __crypto_register_alg already.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @gregkh

    IPV4: Remove bogus ifdef mess in arp_process

    Adrian Bunk authored gregkh committed
    [IPV4]: Remove bogus ifdef mess in arp_process
    
    [ Upstream commit: 3660019 ]
    
    The #ifdef's in arp_process() were not only a mess, they were also wrong
    in the CONFIG_NET_ETHERNET=n and (CONFIG_NETDEV_1000=y or
    CONFIG_NETDEV_10000=y) cases.
    
    Since they are not required this patch removes them.
    
    Also removed are some #ifdef's around #include's that caused compile
    errors after this change.
    
    Signed-off-by: Adrian Bunk <bunk@kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: David Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @gregkh

    NET: Corrects a bug in ip_rt_acct_read()

    Eric Dumazet authored gregkh committed
    [NET]: Corrects a bug in ip_rt_acct_read()
    
    [ Upstream commit: 483b23f ]
    
    It seems that stats of cpu 0 are counted twice, since
    for_each_possible_cpu() is looping on all possible cpus, including 0
    
    Before percpu conversion of ip_rt_acct, we should also remove the
    assumption that CPU 0 is online (or even possible)
    
    Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    PFKEY: Sending an SADB_GET responds with an SADB_GET

    Charles Hardin authored gregkh committed
    [PFKEY]: Sending an SADB_GET responds with an SADB_GET
    
    [ Upstream commit: 435000b ]
    
    Kernel needs to respond to an SADB_GET with the same message type to
    conform to the RFC 2367 Section 3.1.5
    
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @gregkh

    TCP: MTUprobe: fix potential sk_send_head corruption

    Ilpo Järvinen authored gregkh committed
    [TCP] MTUprobe: fix potential sk_send_head corruption
    
    [ Upstream commit: 6e42141 ]
    
    When the abstraction functions got added, conversion here was
    made incorrectly. As a result, the skb may end up pointing
    to skb which got included to the probe skb and then was freed.
    For it to trigger, however, skb_transmit must fail sending as
    well.
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @gregkh

    TCP: Problem bug with sysctl_tcp_congestion_control function

    Sam Jansen authored gregkh committed
    [TCP]: Problem bug with sysctl_tcp_congestion_control function
    
    [ Upstream commit: 5487796 ]
    
    sysctl_tcp_congestion_control seems to have a bug that prevents it
    from actually calling the tcp_set_default_congestion_control
    function. This is not so apparent because it does not return an error
    and generally the /proc interface is used to configure the default TCP
    congestion control algorithm.  This is present in 2.6.18 onwards and
    probably earlier, though I have not inspected 2.6.15--2.6.17.
    
    sysctl_tcp_congestion_control calls sysctl_string and expects a successful
    return code of 0. In such a case it actually sets the congestion control
    algorithm with tcp_set_default_congestion_control. Otherwise, it returns the
    value returned by sysctl_string. This was correct in 2.6.14, as sysctl_string
    returned 0 on success. However, sysctl_string was updated to return 1 on
    success around about 2.6.15 and sysctl_tcp_congestion_control was not updated.
    Even though sysctl_tcp_congestion_control returns 1, do_sysctl_strategy
    converts this return code to '0', so the caller never notices the error.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @gregkh

    fb_ddc: fix DDC lines quirk

    Jean Delvare authored gregkh committed
    patch b64d708 in mainline.
    
    The code in fb_ddc_read() is said to be based on the implementation of the
    radeon driver:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fc5891c8a3ba284f13994d7bc1f1bfa8283982de
    
    However, comparing the old radeon driver code with the new fb_ddc code
    reveals some differences.  Most notably, the I2C bus lines are held at the
    end of the function, while the original code was releasing them (as the
    comment above correctly says.)
    
    There are a few other differences, which appear to be responsible for read
    failures on my system.  While tracing low-level I2C code in i2c-algo-bit, I
    noticed that the initial attempt to read the EDID always failed.  It takes
    one retry for the read to succeed.  As we are about to remove this
    automatic retry property from i2c-algo-bit, reading the EDID would really
    fail.
    
    As a summary, the I2C lines quirk which is supposedly needed to read EDID
    on some older monitors is currently breaking the (first) read on all other
    monitors (and might not even work with older ones - did anyone try since
    October 2006?)
    
    After applying the patch below, which makes the code in fb_ddc_read()
    really similar to what the radeon driver used to have, the first EDID read
    succeeds again.
    
    On top of that, as it appears that this code has been broken for one year
    now and nobody seems to have complained, I'm curious if it makes sense to
    keep this quirk in place.  It makes the code more complex and slower just
    for the sake of monitors which I guess nobody uses anymore.  Can't we just
    get rid of it?
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Tested-by: Roger Leigh <rleigh@whinlatter.ukfsn.org>
    Tested-by: Michael Buesch <mb@bu3sch.de>
    Cc: "Antonino A. Daplas" <adaplas@pol.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    forcedeth boot delay fix

    Ayaz Abdulla authored gregkh committed
    patch 9e55593 in mainline.
    
    Fix a long boot delay in the forcedeth driver.  During initialization, the
    timeout for the handshake between mgmt unit and driver can be very long.
    The patch reduces the timeout by eliminating a extra loop around the
    timeout logic.
    
    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9308
    
    Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
    Cc: Alex Howells <astinus@gentoo.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Jeff Garzik <jeff@garzik.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    forcedeth: new mcp79 pci ids

    Ayaz Abdulla authored gregkh committed
    patch 490dde8 in mainline.
    
    This patch adds new device ids and features for mcp79 devices into the
    forcedeth driver.
    
    Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    
    index 92ce2e3..f9ba0ac 100644
  25. @gregkh

    futex: fix for futex_wait signal stack corruption

    Steven Rostedt authored gregkh committed
    From Steven Rostedt <srostedt@redhat.com>
    
    patch ce6bd42 in mainline.
    
    David Holmes found a bug in the -rt tree with respect to
    pthread_cond_timedwait. After trying his test program on the latest git
    from mainline, I found the bug was there too.  The bug he was seeing
    that his test program showed, was that if one were to do a "Ctrl-Z" on a
    process that was in the pthread_cond_timedwait, and then did a "bg" on
    that process, it would return with a "-ETIMEDOUT" but early. That is,
    the timer would go off early.
    
    Looking into this, I found the source of the problem. And it is a rather
    nasty bug at that.
    
    Here's the relevant code from kernel/futex.c: (not in order in the file)
    
    [...]
    smlinkage long sys_futex(u32 __user *uaddr, int op, u32 val,
                              struct timespec __user *utime, u32 __user *uaddr2,
                              u32 val3)
    {
            struct timespec ts;
            ktime_t t, *tp = NULL;
            u32 val2 = 0;
            int cmd = op & FUTEX_CMD_MASK;
    
            if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI)) {
                    if (copy_from_user(&ts, utime, sizeof(ts)) != 0)
                            return -EFAULT;
                    if (!timespec_valid(&ts))
                            return -EINVAL;
    
                    t = timespec_to_ktime(ts);
                    if (cmd == FUTEX_WAIT)
                            t = ktime_add(ktime_get(), t);
                    tp = &t;
            }
    [...]
            return do_futex(uaddr, op, val, tp, uaddr2, val2, val3);
    }
    
    [...]
    
    long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout,
                    u32 __user *uaddr2, u32 val2, u32 val3)
    {
            int ret;
            int cmd = op & FUTEX_CMD_MASK;
            struct rw_semaphore *fshared = NULL;
    
            if (!(op & FUTEX_PRIVATE_FLAG))
                    fshared = &current->mm->mmap_sem;
    
            switch (cmd) {
            case FUTEX_WAIT:
                    ret = futex_wait(uaddr, fshared, val, timeout);
    
    [...]
    
    static int futex_wait(u32 __user *uaddr, struct rw_semaphore *fshared,
                          u32 val, ktime_t *abs_time)
    {
    [...]
                   struct restart_block *restart;
                    restart = &current_thread_info()->restart_block;
                    restart->fn = futex_wait_restart;
                    restart->arg0 = (unsigned long)uaddr;
                    restart->arg1 = (unsigned long)val;
                    restart->arg2 = (unsigned long)abs_time;
                    restart->arg3 = 0;
                    if (fshared)
                            restart->arg3 |= ARG3_SHARED;
                    return -ERESTART_RESTARTBLOCK;
    [...]
    
    static long futex_wait_restart(struct restart_block *restart)
    {
            u32 __user *uaddr = (u32 __user *)restart->arg0;
            u32 val = (u32)restart->arg1;
            ktime_t *abs_time = (ktime_t *)restart->arg2;
            struct rw_semaphore *fshared = NULL;
    
            restart->fn = do_no_restart_syscall;
            if (restart->arg3 & ARG3_SHARED)
                    fshared = &current->mm->mmap_sem;
            return (long)futex_wait(uaddr, fshared, val, abs_time);
    }
    
    So when the futex_wait is interrupt by a signal we break out of the
    hrtimer code and set up or return from signal. This code does not return
    back to userspace, so we set up a RESTARTBLOCK.  The bug here is that we
    save the "abs_time" which is a pointer to the stack variable "ktime_t t"
    from sys_futex.
    
    This returns and unwinds the stack before we get to call our signal. On
    return from the signal we go to futex_wait_restart, where we update all
    the parameters for futex_wait and call it. But here we have a problem
    where abs_time is no longer valid.
    
    I verified this with print statements, and sure enough, what abs_time
    was set to ends up being garbage when we get to futex_wait_restart.
    
    The solution I did to solve this (with input from Linus Torvalds)
    was to add unions to the restart_block to allow system calls to
    use the restart with specific parameters.  This way the futex code now
    saves the time in a 64bit value in the restart block instead of storing
    it on the stack.
    
    Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64
    in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
    Not sure what that is there for.  If this turns out to be a problem, I've
    tested this with using "unsigned int" for u32 and "unsigned long long" for
    u64 and it worked just the same. I'm using u32 and u64 just to be
    consistent with what the futex code uses.
    
    Signed-off-by: Steven Rostedt <srostedt@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @gregkh

    hrtimers: avoid overflow for large relative timeouts (CVE-2007-5966)

    Thomas Gleixner authored gregkh committed
    patch 62f0f61 in mainline
    
    Relative hrtimers with a large timeout value might end up as negative
    timer values, when the current time is added in hrtimer_start().
    
    This in turn is causing the clockevents_set_next() function to set an
    huge timeout and sleep for quite a long time when we have a clock
    source which is capable of long sleeps like HPET. With PIT this almost
    goes unnoticed as the maximum delta is ~27ms. The non-hrt/nohz code
    sorts this out in the next timer interrupt, so we never noticed that
    problem which has been there since the first day of hrtimers.
    
    This bug became more apparent in 2.6.24 which activates HPET on more
    hardware.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @gregkh

    I4L: fix isdn_ioctl memory overrun vulnerability

    Karsten Keil authored gregkh committed
    patch eafe1aa in mainline.
    
    Fix possible memory overrun issue in the isdn ioctl code.  Found by ADLAB
    <adlab@venustech.com.cn>
    
    Signed-off-by: Karsten Keil <kkeil@suse.de>
    Cc: ADLAB <adlab@venustech.com.cn>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @gregkh

    isdn: avoid copying overly-long strings

    Karsten Keil authored gregkh committed
    patch 0f13864 in mainline.
    
    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9416
    
    Signed-off-by: Karsten Keil <kkeil@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @herbertx @gregkh

    libcrc32c: keep intermediate crc state in cpu order

    herbertx authored gregkh committed
    It's upstream changeset ef19454.
    
    [LIB] crc32c: Keep intermediate crc state in cpu order
    
    crypto/crc32.c:chksum_final() is computing the digest as
    *(__le32 *)out = ~cpu_to_le32(mctx->crc);
    so the low-level crc32c_le routines should just keep
    the crc in cpu order, otherwise it is getting swabbed
    one too many times on big-endian machines.
    
    Signed-off-by: Benny Halevy <bhalevy@fs1.bhalevy.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @gregkh

    nf_nat: fix memset error

    Li Zefan authored gregkh committed
    This patch fixes an incorrect memset in the NAT code, causing
    misbehaviour when unloading and reloading the NAT module.
    Applies to stable-2.6.22 and stable-2.6.23.
    
    Please apply, thanks.
    [NETFILTER]: nf_nat: fix memset error
    
    Upstream commit e0bf9cf
    
    The size passing to memset is the size of a pointer. Fixes
    misbehaviour when unloading and reloading the NAT module.
    
    Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  31. @gregkh

    tmpfs: restore missing clear_highpage

    Hugh Dickins authored gregkh committed
    patch e84e2e1 in mainline
    
    tmpfs was misconverted to __GFP_ZERO in 2.6.11.  There's an unusual case in
    which shmem_getpage receives the page from its caller instead of allocating.
    We must cover this case by clear_highpage before SetPageUptodate, as before.
    
    Signed-off-by: Hugh Dickins <hugh@veritas.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @gregkh

    USB: fix up EHCI startup synchronization

    David Brownell authored gregkh committed
    patch 1cb5265 in mainline.
    
    A recent patch added software synchronization during EHCI startup,
    so ports aren't switched away from the companion controllers after
    resets have started.  This patch adds a short delay letting hardware
    finish that port switching before any new resets begin ... so both
    ends of that hardware race window are closed.
    
    Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
    Cc: Dave Miller <davem@davemloft.net>
    Cc: Dely Sy <dely.l.sy@intel.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @gregkh

    USB: make the microtek driver and HAL cooperate

    Oliver Neukum authored gregkh committed
    patch 5cf1973 in mainline
    
    to make HAL like the microtek driver's devices the parent must be
    correctly set.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.