kernel-packages team mailing list archive

[Andy Whitcroft <apw@xxxxxxxxxxxxx>]

** Changed in: linux-fsl-imx51 (Ubuntu Lucid)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-backport-maverick in Ubuntu.
https://bugs.launchpad.net/bugs/799828

Title:
  CVE-2010-4526

Status in linux package in Ubuntu:
  Invalid
Status in linux-fsl-imx51 package in Ubuntu:
  Invalid
Status in linux-lts-backport-maverick package in Ubuntu:
  Invalid
Status in linux-mvl-dove package in Ubuntu:
  Invalid
Status in linux-ti-omap4 package in Ubuntu:
  Invalid
Status in linux source package in Lucid:
  Fix Released
Status in linux-fsl-imx51 source package in Lucid:
  Fix Released
Status in linux-lts-backport-maverick source package in Lucid:
  Invalid
Status in linux-mvl-dove source package in Lucid:
  Invalid
Status in linux-ti-omap4 source package in Lucid:
  Invalid
Status in linux source package in Maverick:
  Invalid
Status in linux-fsl-imx51 source package in Maverick:
  Invalid
Status in linux-lts-backport-maverick source package in Maverick:
  Invalid
Status in linux-mvl-dove source package in Maverick:
  Invalid
Status in linux-ti-omap4 source package in Maverick:
  Invalid
Status in linux source package in Natty:
  Invalid
Status in linux-fsl-imx51 source package in Natty:
  Invalid
Status in linux-lts-backport-maverick source package in Natty:
  Invalid
Status in linux-mvl-dove source package in Natty:
  Invalid
Status in linux-ti-omap4 source package in Natty:
  Invalid
Status in linux source package in Oneiric:
  Invalid
Status in linux-fsl-imx51 source package in Oneiric:
  Invalid
Status in linux-lts-backport-maverick source package in Oneiric:
  Invalid
Status in linux-mvl-dove source package in Oneiric:
  Invalid
Status in linux-ti-omap4 source package in Oneiric:
  Invalid
Status in linux source package in Hardy:
  Fix Released
Status in linux-fsl-imx51 source package in Hardy:
  Invalid
Status in linux-lts-backport-maverick source package in Hardy:
  Invalid
Status in linux-mvl-dove source package in Hardy:
  Invalid
Status in linux-ti-omap4 source package in Hardy:
  Invalid

Bug description:
  Fixed-by: 50b5d6ad63821cea324a5a7a19854d4de1a0a819

  
    commit 50b5d6ad63821cea324a5a7a19854d4de1a0a819
    Author: Vlad Yasevich <vladislav.yasevich@xxxxxx>
    Date:   Thu May 6 00:56:07 2010 -0700

      sctp: Fix a race between ICMP protocol unreachable and connect()
      
      ICMP protocol unreachable handling completely disregarded
      the fact that the user may have locked the socket.  It proceeded
      to destroy the association, even though the user may have
      held the lock and had a ref on the association.  This resulted
      in the following:
      
      Attempt to release alive inet socket f6afcc00
      
      =========================
      [ BUG: held lock freed! ]
      -------------------------
      somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held
      there!
       (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c
      1 lock held by somenu/2672:
       #0:  (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c
      
      stack backtrace:
      Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55
      Call Trace:
       [<c1232266>] ? printk+0xf/0x11
       [<c1038553>] debug_check_no_locks_freed+0xce/0xff
       [<c10620b4>] kmem_cache_free+0x21/0x66
       [<c1185f25>] __sk_free+0x9d/0xab
       [<c1185f9c>] sk_free+0x1c/0x1e
       [<c1216e38>] sctp_association_put+0x32/0x89
       [<c1220865>] __sctp_connect+0x36d/0x3f4
       [<c122098a>] ? sctp_connect+0x13/0x4c
       [<c102d073>] ? autoremove_wake_function+0x0/0x33
       [<c12209a8>] sctp_connect+0x31/0x4c
       [<c11d1e80>] inet_dgram_connect+0x4b/0x55
       [<c11834fa>] sys_connect+0x54/0x71
       [<c103a3a2>] ? lock_release_non_nested+0x88/0x239
       [<c1054026>] ? might_fault+0x42/0x7c
       [<c1054026>] ? might_fault+0x42/0x7c
       [<c11847ab>] sys_socketcall+0x6d/0x178
       [<c10da994>] ? trace_hardirqs_on_thunk+0xc/0x10
       [<c1002959>] syscall_call+0x7/0xb
      
      This was because the sctp_wait_for_connect() would aqcure the socket
      lock and then proceed to release the last reference count on the
      association, thus cause the fully destruction path to finish freeing
      the socket.
      
      The simplest solution is to start a very short timer in case the socket
      is owned by user.  When the timer expires, we can do some verification
      and be able to do the release properly.
      
      Signed-off-by: Vlad Yasevich <vladislav.yasevich@xxxxxx>
      Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/799828/+subscriptions