From: Paolo Abeni
Date: Thu, 27 Jul 2017 14:45:09 +0200
> When an early demuxed packet reaches __udp6_lib_lookup_skb(), the
> sk reference is retrieved and used, but the relevant reference
> count is leaked and the socket destructor is never called.
> Beyond leaking the sk
On Thu, 2017-07-27 at 14:45 +0200, Paolo Abeni wrote:
> When an early demuxed packet reaches __udp6_lib_lookup_skb(), the
> sk reference is retrieved and used, but the relevant reference
> count is leaked and the socket destructor is never called.
> Beyond leaking the sk memory, if there are
Hi David,
I'm sorry but I'm really too low on coffee and I missed adding the
proper v2 tag in the subject. Please let me know if you prefer I repost
with a proper subject or if you prefer otherwise.
Thanks!
Paolo
When an early demuxed packet reaches __udp6_lib_lookup_skb(), the
sk reference is retrieved and used, but the relevant reference
count is leaked and the socket destructor is never called.
Beyond leaking the sk memory, if there are pending UDP packets
in the receive queue, even the related
On Thu, 2017-07-27 at 00:06 -0700, Eric Dumazet wrote:
> On Wed, 2017-07-26 at 17:29 +0200, Paolo Abeni wrote:
> > When an early demuxed packet reaches __udp6_lib_lookup_skb(), the
> > sk reference is retrieved and used, but the relevant reference
> > count is leaked and the socket destructor is
On Wed, 2017-07-26 at 17:29 +0200, Paolo Abeni wrote:
> When an early demuxed packet reaches __udp6_lib_lookup_skb(), the
> sk reference is retrieved and used, but the relevant reference
> count is leaked and the socket destructor is never called.
> Beyond leaking the sk memory, if there are
When an early demuxed packet reaches __udp6_lib_lookup_skb(), the
sk reference is retrieved and used, but the relevant reference
count is leaked and the socket destructor is never called.
Beyond leaking the sk memory, if there are pending UDP packets
in the receive queue, even the related