[PATCH 00/11] [lucid/master] CVE-2010-4251 v2

Tim Gardner tim.gardner at canonical.com
Mon Jul 11 15:23:17 UTC 2011


On 07/11/2011 08:20 AM, Paolo Pisati wrote:
> All patches but 4 (ipv4: udp: Optimise multicast reception) are clean cherry-picks from upstream.
> Patches 3-5 are not related to this CVE, but 6 depends on them.
> Tested on a lucid qemu image: boot test plus an entire system `apt-get upgrade`.
>
> Eric Dumazet (3):
>    ipv6: udp: Optimise multicast reception
>    ipv4: udp: Optimise multicast reception
>    udp: multicast RX should increment SNMP/sk_drops counter in
>      allocation failures CVE-2010-4251
>
> Zhu Yi (8):
>    net: add limit for socket backlog CVE-2010-4251
>    tcp: use limited socket backlog CVE-2010-4251
>    udp: use limited socket backlog CVE-2010-4251
>    llc: use limited socket backlog CVE-2010-4251
>    sctp: use limited socket backlog CVE-2010-4251
>    tipc: use limited socket backlog CVE-2010-4251
>    x25: use limited socket backlog CVE-2010-4251
>    net: backlog functions rename CVE-2010-4251
>
>   include/net/sock.h       |   17 +++++++-
>   net/core/sock.c          |   16 +++++++-
>   net/dccp/minisocks.c     |    2 +-
>   net/ipv4/tcp_ipv4.c      |    6 ++-
>   net/ipv4/tcp_minisocks.c |    2 +-
>   net/ipv4/udp.c           |   92 ++++++++++++++++++++++++++++++++--------------
>   net/ipv6/tcp_ipv6.c      |    6 ++-
>   net/ipv6/udp.c           |   89 +++++++++++++++++++++++++++++++-------------
>   net/llc/llc_c_ac.c       |    2 +-
>   net/llc/llc_conn.c       |    3 +-
>   net/sctp/input.c         |   42 +++++++++++++-------
>   net/sctp/socket.c        |    3 +
>   net/tipc/socket.c        |    6 ++-
>   net/x25/x25_dev.c        |    2 +-
>   14 files changed, 204 insertions(+), 84 deletions(-)
>

While researching these patches I stumbled across some further analysis 
of this vulnerability by Eugene Teo at 
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-4251 in which he 
includes a 2.6.35 patch from Eric Duzamet which really, really fixes the 
problem.

If we're gonna wreak this level of havoc on the network layer, then we 
might as well go all the way. Also, with more then 2 patches in a series 
I prefer a pull request.

rtg
-- 
Tim Gardner tim.gardner at canonical.com




More information about the kernel-team mailing list