23 Sep, 2006

1 commit


01 Jul, 2006

1 commit


21 Mar, 2006

7 commits


04 Jan, 2006

4 commits


01 Nov, 2005

2 commits

  • Here is a complimentary insurance policy for those feeling a bit insecure.
    You don't have to accept this. However, if you do, you can't blame me for
    it :)

    > 1) dccp_transmit_skb sets the owner for all packets except data packets.

    We can actually verify this by looking at pkt_type.

    Signed-off-by: Herbert Xu
    Signed-off-by: Arnaldo Carvalho de Melo

    Herbert Xu
     
  • While we're at it let's reorganise the set_owner_w calls a little so that:

    1) dccp_transmit_skb sets the owner for all packets except data packets.
    2) Add dccp_skb_entail to set owner for packets queued for retransmission.
    3) Make dccp_transmit_skb static.

    Signed-off-by: Herbert Xu
    Signed-off-by: Arnaldo Carvalho de Melo

    Herbert Xu
     

28 Oct, 2005

1 commit


21 Oct, 2005

3 commits

  • Turns out the problem has nothing to do with use-after-free or double-free.
    It's just that we're not clearing the CB area and DCCP unlike TCP uses a CB
    format that's incompatible with IP.

    Signed-off-by: Herbert Xu
    Signed-off-by: Ian McDonald
    Signed-off-by: Arnaldo Carvalho de Melo

    Herbert Xu
     
  • icmp_send doesn't use skb->sk at all so even if skb->sk has already
    been freed it can't cause crash there (it would've crashed somewhere
    else first, e.g., ip_queue_xmit).

    I found a double-free on an skb that could explain this though.
    dccp_sendmsg and dccp_write_xmit are a little confused as to what
    should free the packet when something goes wrong. Sometimes they
    both go for the ball and end up in each other's way.

    This patch makes dccp_write_xmit always free the packet no matter
    what. This makes sense since dccp_transmit_skb which in turn comes
    from the fact that ip_queue_xmit always frees the packet.

    Signed-off-by: Herbert Xu
    Signed-off-by: Arnaldo Carvalho de Melo

    Herbert Xu
     
  • David S. Miller wrote:
    > One thing you can probably do for this bug is to mark data packets
    > explicitly somehow, perhaps in the SKB control block DCCP already
    > uses for other data. Put some boolean in there, set it true for
    > data packets. Then change the test in dccp_transmit_skb() as
    > appropriate to test the boolean flag instead of "skb_cloned(skb)".

    I agree. In fact we already have that flag, it's called skb->sk.
    So here is patch to test that instead of skb_cloned().

    Signed-off-by: Herbert Xu
    Acked-by: Ian McDonald
    Signed-off-by: Arnaldo Carvalho de Melo

    Herbert Xu
     

18 Sep, 2005

1 commit


17 Sep, 2005

1 commit

  • As discussed in the dccp@vger mailing list:

    Now applications have to use setsockopt(DCCP_SOCKOPT_SERVICE, service[s]),
    prior to calling listen() and connect().

    An array of unsigned ints can be passed meaning that the listening sock accepts
    connection requests for several services.

    With this we can ditch struct sockaddr_dccp and use only sockaddr_in (and
    sockaddr_in6 in the future).

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

10 Sep, 2005

1 commit


30 Aug, 2005

10 commits