On Mon, Feb 18, 2019 at 2:12 PM Willem de Bruijn
wrote:
>
> On Fri, Feb 15, 2019 at 12:15 PM Willem de Bruijn
> wrote:
> >
> > From: Willem de Bruijn
> >
> > Syzkaller again found a path to a kernel crash through bad gso input.
> > By building an excessively large packet to cause an skb field to
On Fri, Feb 15, 2019 at 12:15 PM Willem de Bruijn
wrote:
>
> From: Willem de Bruijn
>
> Syzkaller again found a path to a kernel crash through bad gso input.
> By building an excessively large packet to cause an skb field to wrap.
>
> If VIRTIO_NET_HDR_F_NEEDS_CSUM was set this would have been dr
From: Willem de Bruijn
Date: Fri, 15 Feb 2019 12:15:47 -0500
> From: Willem de Bruijn
>
> Syzkaller again found a path to a kernel crash through bad gso input.
> By building an excessively large packet to cause an skb field to wrap.
>
> If VIRTIO_NET_HDR_F_NEEDS_CSUM was set this would have be
On 02/15/2019 09:15 AM, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> Syzkaller again found a path to a kernel crash through bad gso input.
> By building an excessively large packet to cause an skb field to wrap.
>
> If VIRTIO_NET_HDR_F_NEEDS_CSUM was set this would have been dropped i
From: Willem de Bruijn
Syzkaller again found a path to a kernel crash through bad gso input.
By building an excessively large packet to cause an skb field to wrap.
If VIRTIO_NET_HDR_F_NEEDS_CSUM was set this would have been dropped in
skb_partial_csum_set.
GSO packets that do not set checksum o
On 2018年01月19日 22:39, Willem de Bruijn wrote:
On Fri, Jan 19, 2018 at 3:19 AM, Jason Wang wrote:
On 2018年01月19日 08:53, Willem de Bruijn wrote:
And what you propose here is just a very small subset of the
necessary checking, more comes at gso header checking. So even if we
care
performance,
On Fri, Jan 19, 2018 at 3:19 AM, Jason Wang wrote:
>
>
> On 2018年01月19日 08:53, Willem de Bruijn wrote:
>
> And what you propose here is just a very small subset of the
> necessary checking, more comes at gso header checking. So even if we
> care
> performance, it only help for
On 2018年01月19日 08:53, Willem de Bruijn wrote:
And what you propose here is just a very small subset of the
necessary checking, more comes at gso header checking. So even if we care
performance, it only help for some specific case.
It also fixed the bug that Eric sent a separate patch for, as t
>>> This implements subset of function for codes which was removed by the
>>> commit
>>> I mentioned below.
>>
>> No, as I explain above, it performs a different check.
>>
>
>
> [...]
Clearly I was wrong, sorry. Thanks for pointing out that commit and
576a30eb6453 ("[NET]: Added GSO header ver
On 2018年01月18日 13:09, Willem de Bruijn wrote:
Also, a packet can just as easily spoof an esp packet.
See also the discussion in the Link above.
Then we probably need check there.
Adding a check in every gso handler that does not expect packets
with SKB_GSO_DODGY source seems backwards to m
virtio_net_hdr_to_skb checks gso_type, but it does not verify that this
type correctly describes the actual packet. Segmentation happens based
on packet contents. So a packet was crafted to enter sctp gso, even
though no such gso_type exists. This issue is not specific to sctp.
On 2018年01月17日 22:27, Willem de Bruijn wrote:
On Wed, Jan 17, 2018 at 6:54 AM, Jason Wang wrote:
On 2018年01月17日 12:33, Willem de Bruijn wrote:
On Tue, Jan 16, 2018 at 11:04 PM, Jason Wang wrote:
On 2018年01月17日 04:29, Willem de Bruijn wrote:
From: Willem de Bruijn
Validate gso packet ty
> From: Willem de Bruijn
>
> Validate gso packet type and headers on kernel entry. Reuse the info
> gathered by skb_probe_transport_header.
>
> Syzbot found two bugs by passing bad gso packets in packet sockets.
> Untrusted user packets are limited to a small set of gso
On Wed, Jan 17, 2018 at 6:54 AM, Jason Wang wrote:
>
>
> On 2018年01月17日 12:33, Willem de Bruijn wrote:
>>
>> On Tue, Jan 16, 2018 at 11:04 PM, Jason Wang wrote:
>>>
>>>
>>> On 2018年01月17日 04:29, Willem de Bruijn wrote:
From: Willem de Bruijn
Validate gso packet type and header
On 2018年01月17日 12:56, Willem de Bruijn wrote:
This just makes that check more strict. Frequency of malicious packets is
not really relevant if a single bad packet can cause damage.
The alternative to validate on kernel entry is to harden the entire segmentation
layer and lower part of the stac
On 2018年01月17日 12:33, Willem de Bruijn wrote:
On Tue, Jan 16, 2018 at 11:04 PM, Jason Wang wrote:
On 2018年01月17日 04:29, Willem de Bruijn wrote:
From: Willem de Bruijn
Validate gso packet type and headers on kernel entry. Reuse the info
gathered by skb_probe_transport_header.
Syzbot found
On Tue, Jan 16, 2018 at 11:33 PM, Willem de Bruijn
wrote:
> On Tue, Jan 16, 2018 at 11:04 PM, Jason Wang wrote:
>>
>>
>> On 2018年01月17日 04:29, Willem de Bruijn wrote:
>>>
>>> From: Willem de Bruijn
>>>
>>> Validate gso packet type and headers on kernel entry. Reuse the info
>>> gathered by skb_pr
On Tue, Jan 16, 2018 at 11:04 PM, Jason Wang wrote:
>
>
> On 2018年01月17日 04:29, Willem de Bruijn wrote:
>>
>> From: Willem de Bruijn
>>
>> Validate gso packet type and headers on kernel entry. Reuse the info
>> gathered by skb_probe_transport_header.
>>
>> Syzbot found two bugs by passing bad gso
On 2018年01月17日 04:29, Willem de Bruijn wrote:
From: Willem de Bruijn
Validate gso packet type and headers on kernel entry. Reuse the info
gathered by skb_probe_transport_header.
Syzbot found two bugs by passing bad gso packets in packet sockets.
Untrusted user packets are limited to a small s
From: Willem de Bruijn
Validate gso packet type and headers on kernel entry. Reuse the info
gathered by skb_probe_transport_header.
Syzbot found two bugs by passing bad gso packets in packet sockets.
Untrusted user packets are limited to a small set of gso types in
virtio_net_hdr_to_skb. But seg
20 matches
Mail list logo
