From: Defang Bo
Date: Sun, 27 Dec 2020 22:11:35 +0800
> Similar to commit<2423496af35>, the fragmentation code tries to parse the
> header options in order
> to figure out where to insert the fragment option. Since nexthdr points
> to an invalid option, the calculation of the size of the
Similar to commit<2423496af35>, the fragmentation code tries to parse the
header options in order
to figure out where to insert the fragment option. Since nexthdr points
to an invalid option, the calculation of the size of the network header
can made to be much larger than the linear section of
On 6/3/19 11:59 PM, Yang Xiao wrote:
> Sorry, I don't get your point. Why is xfrm6_transport_output() buggy?
> The point is that there would be out-of-bound access in
> mip6_destopt_offset() and mip6_destopt_offset(), since there is no
> sanity check for offset.
>
> There is chance that offset
Sorry, I don't get your point. Why is xfrm6_transport_output() buggy?
The point is that there would be out-of-bound access in
mip6_destopt_offset() and mip6_destopt_offset(), since there is no
sanity check for offset.
There is chance that offset + sizeof(struct ipv6_opt_hdr) > packet_len.
As
On 5/30/19 8:04 PM, Yang Xiao wrote:
> On Fri, May 31, 2019 at 1:17 AM Eric Dumazet wrote:
>>
>>
>>
>> On 5/30/19 8:28 AM, Young Xiao wrote:
>>> The fragmentation code tries to parse the header options in order
>>> to figure out where to insert the fragment option. Since nexthdr points
>>> to
On Fri, May 31, 2019 at 11:57 PM Eric Dumazet wrote:
>
>
>
> On 5/31/19 7:54 AM, Herbert Xu wrote:
> > On Fri, May 31, 2019 at 07:50:06AM -0700, Eric Dumazet wrote:
> >>
> >> What do you mean by should ?
> >>
> >> Are they currently already linearized before the function is called,
> >> or is it
On 5/31/19 7:54 AM, Herbert Xu wrote:
> On Fri, May 31, 2019 at 07:50:06AM -0700, Eric Dumazet wrote:
>>
>> What do you mean by should ?
>>
>> Are they currently already linearized before the function is called,
>> or is it missing and a bug needs to be fixed ?
>
> AFAICS this is the code-path
On Fri, May 31, 2019 at 07:50:06AM -0700, Eric Dumazet wrote:
>
> What do you mean by should ?
>
> Are they currently already linearized before the function is called,
> or is it missing and a bug needs to be fixed ?
AFAICS this is the code-path for locally generated outbound packets.
Under what
On 5/30/19 11:29 PM, Herbert Xu wrote:
> On Thu, May 30, 2019 at 10:17:04AM -0700, Eric Dumazet wrote:
>>
>> xfrm6_transport_output() seems buggy as well,
>> unless the skbs are linearized before entering these functions ?
>
> The headers that it's moving should be linearised. Is there
>
On Thu, May 30, 2019 at 10:17:04AM -0700, Eric Dumazet wrote:
>
> xfrm6_transport_output() seems buggy as well,
> unless the skbs are linearized before entering these functions ?
The headers that it's moving should be linearised. Is there
something else I'm missing?
Cheers,
--
Email: Herbert
On Fri, May 31, 2019 at 1:17 AM Eric Dumazet wrote:
>
>
>
> On 5/30/19 8:28 AM, Young Xiao wrote:
> > The fragmentation code tries to parse the header options in order
> > to figure out where to insert the fragment option. Since nexthdr points
> > to an invalid option, the calculation of the
On 5/30/19 8:28 AM, Young Xiao wrote:
> The fragmentation code tries to parse the header options in order
> to figure out where to insert the fragment option. Since nexthdr points
> to an invalid option, the calculation of the size of the network header
> can made to be much larger than the
The fragmentation code tries to parse the header options in order
to figure out where to insert the fragment option. Since nexthdr points
to an invalid option, the calculation of the size of the network header
can made to be much larger than the linear section of the skb and data
is read outside
13 matches
Mail list logo
