| To: | dlstevens@xxxxxxxxxx, davem@xxxxxxxxxxxxx |
|---|---|
| Subject: | Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory |
| From: | YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx> |
| Date: | Wed, 13 Apr 2005 13:05:35 +0900 (JST) |
| Cc: | netdev@xxxxxxxxxxx, yoshfuji@xxxxxxxxxxxxxx |
| In-reply-to: | <OF0A4F590E.3F5A449F-ON88256FE2.000E49F8-88256FE2.000F289A@us.ibm.com> |
| Organization: | USAGI Project |
| References: | <20050413.095308.124546011.yoshfuji@linux-ipv6.org> <OF0A4F590E.3F5A449F-ON88256FE2.000E49F8-88256FE2.000F289A@us.ibm.com> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
In article <OF0A4F590E.3F5A449F-ON88256FE2.000E49F8-88256FE2.000F289A@xxxxxxxxxx> (at Tue, 12 Apr 2005 19:45:34 -0700), David Stevens <dlstevens@xxxxxxxxxx> says: > csum has to be a pointer into the packet data, so it can store > the checksum it computes for the outgoing packet at that (user-provided) > offset. It looks like skb_header_pointer gives a copy of the > existing value, pointing to csum_buff, which wouldn't modify the > packet value, right? So, I don't think that'll work. Ok, understood. BTW, I remember that my first intention was that we restrict "checksum" should be placed within the first fragment. In this sense, rp->offset + 1 < len does not make sense to me, if there's more fragments. Anyway, please allow me some time... --yoshfuji |
| Previous by Date: | Re: Question about connect and ipsec, Herbert Xu |
|---|---|
| Next by Date: | Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory, David Stevens |
| Previous by Thread: | Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory, David Stevens |
| Next by Thread: | Re: [PATCH] IPV6_CHECKSUM socket option can corrupt kernel memory, David Stevens |
| Indexes: | [Date] [Thread] [Top] [All Lists] |