| Message ID | 2023113042-unfazed-dioxide-f854@gregkh (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net] net/packet: move reference count in packet_sock to 64 bits | expand |
On 11/30/23 3:20 PM, Greg Kroah-Hartman wrote: > In some potential instances the reference count on struct packet_sock > could be saturated and cause overflows which gets the kernel a bit > confused. To prevent this, move to a 64bit atomic reference count to > prevent the possibility of this type of overflow. > > Because we can not handle saturation, using refcount_t is not possible > in this place. Maybe someday in the future if it changes could it be > used. > > Original version from Daniel after I did it wrong, I've provided a > changelog. > > Reported-by: "The UK's National Cyber Security Centre (NCSC)" <security@ncsc.gov.uk> > Cc: stable <stable@kernel.org> > Cc: Daniel Borkmann <daniel@iogearbox.net> > Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Thanks! Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Daniel Borkmann wrote: > On 11/30/23 3:20 PM, Greg Kroah-Hartman wrote: > > In some potential instances the reference count on struct packet_sock > > could be saturated and cause overflows which gets the kernel a bit > > confused. To prevent this, move to a 64bit atomic reference count to > > prevent the possibility of this type of overflow. > > > > Because we can not handle saturation, using refcount_t is not possible > > in this place. Maybe someday in the future if it changes could it be > > used. > > > > Original version from Daniel after I did it wrong, I've provided a > > changelog. > > > > Reported-by: "The UK's National Cyber Security Centre (NCSC)" <security@ncsc.gov.uk> > > Cc: stable <stable@kernel.org> > > Cc: Daniel Borkmann <daniel@iogearbox.net> > > Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Thanks! > > Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Willem de Bruijn <willemb@google.com>
On 11/30/23 4:15 PM, Willem de Bruijn wrote: > Daniel Borkmann wrote: >> On 11/30/23 3:20 PM, Greg Kroah-Hartman wrote: >>> In some potential instances the reference count on struct packet_sock >>> could be saturated and cause overflows which gets the kernel a bit >>> confused. To prevent this, move to a 64bit atomic reference count to >>> prevent the possibility of this type of overflow. >>> >>> Because we can not handle saturation, using refcount_t is not possible >>> in this place. Maybe someday in the future if it changes could it be >>> used. >>> >>> Original version from Daniel after I did it wrong, I've provided a >>> changelog. >>> >>> Reported-by: "The UK's National Cyber Security Centre (NCSC)" <security@ncsc.gov.uk> >>> Cc: stable <stable@kernel.org> >>> Cc: Daniel Borkmann <daniel@iogearbox.net> >>> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> >>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> >> >> Thanks! >> >> Acked-by: Daniel Borkmann <daniel@iogearbox.net> > > Acked-by: Willem de Bruijn <willemb@google.com> There was feedback from Linus that switching to atomic_long_t is better choice so that it doesn't penalize 32-bit architectures. Will post a v2 today. Thanks, Daniel
On Fri, Dec 01, 2023 at 10:19:35AM +0100, Daniel Borkmann wrote: > On 11/30/23 4:15 PM, Willem de Bruijn wrote: > > Daniel Borkmann wrote: > > > On 11/30/23 3:20 PM, Greg Kroah-Hartman wrote: > > > > In some potential instances the reference count on struct packet_sock > > > > could be saturated and cause overflows which gets the kernel a bit > > > > confused. To prevent this, move to a 64bit atomic reference count to > > > > prevent the possibility of this type of overflow. > > > > > > > > Because we can not handle saturation, using refcount_t is not possible > > > > in this place. Maybe someday in the future if it changes could it be > > > > used. > > > > > > > > Original version from Daniel after I did it wrong, I've provided a > > > > changelog. > > > > > > > > Reported-by: "The UK's National Cyber Security Centre (NCSC)" <security@ncsc.gov.uk> > > > > Cc: stable <stable@kernel.org> > > > > Cc: Daniel Borkmann <daniel@iogearbox.net> > > > > Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > Thanks! > > > > > > Acked-by: Daniel Borkmann <daniel@iogearbox.net> > > > > Acked-by: Willem de Bruijn <willemb@google.com> > > There was feedback from Linus that switching to atomic_long_t is better > choice so that it doesn't penalize 32-bit architectures. Will post a v2 > today. Thanks, makes sense to do it that way. greg k-h
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index a84e00b5904b..9356b661c3d9 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -4300,7 +4300,7 @@ static void packet_mm_open(struct vm_area_struct *vma) struct sock *sk = sock->sk; if (sk) - atomic_inc(&pkt_sk(sk)->mapped); + atomic64_inc(&pkt_sk(sk)->mapped); } static void packet_mm_close(struct vm_area_struct *vma) @@ -4310,7 +4310,7 @@ static void packet_mm_close(struct vm_area_struct *vma) struct sock *sk = sock->sk; if (sk) - atomic_dec(&pkt_sk(sk)->mapped); + atomic64_dec(&pkt_sk(sk)->mapped); } static const struct vm_operations_struct packet_mmap_ops = { @@ -4405,7 +4405,7 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u, err = -EBUSY; if (!closing) { - if (atomic_read(&po->mapped)) + if (atomic64_read(&po->mapped)) goto out; if (packet_read_pending(rb)) goto out; @@ -4508,7 +4508,7 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u, err = -EBUSY; mutex_lock(&po->pg_vec_lock); - if (closing || atomic_read(&po->mapped) == 0) { + if (closing || atomic64_read(&po->mapped) == 0) { err = 0; spin_lock_bh(&rb_queue->lock); swap(rb->pg_vec, pg_vec); @@ -4526,9 +4526,9 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u, po->prot_hook.func = (po->rx_ring.pg_vec) ? tpacket_rcv : packet_rcv; skb_queue_purge(rb_queue); - if (atomic_read(&po->mapped)) - pr_err("packet_mmap: vma is busy: %d\n", - atomic_read(&po->mapped)); + if (atomic64_read(&po->mapped)) + pr_err("packet_mmap: vma is busy: %lld\n", + atomic64_read(&po->mapped)); } mutex_unlock(&po->pg_vec_lock); @@ -4606,7 +4606,7 @@ static int packet_mmap(struct file *file, struct socket *sock, } } - atomic_inc(&po->mapped); + atomic64_inc(&po->mapped); vma->vm_ops = &packet_mmap_ops; err = 0; diff --git a/net/packet/internal.h b/net/packet/internal.h index d29c94c45159..24acd0044a0d 100644 --- a/net/packet/internal.h +++ b/net/packet/internal.h @@ -122,7 +122,7 @@ struct packet_sock { __be16 num; struct packet_rollover *rollover; struct packet_mclist *mclist; - atomic_t mapped; + atomic64_t mapped; enum tpacket_versions tp_version; unsigned int tp_hdrlen; unsigned int tp_reserve;
In some potential instances the reference count on struct packet_sock could be saturated and cause overflows which gets the kernel a bit confused. To prevent this, move to a 64bit atomic reference count to prevent the possibility of this type of overflow. Because we can not handle saturation, using refcount_t is not possible in this place. Maybe someday in the future if it changes could it be used. Original version from Daniel after I did it wrong, I've provided a changelog. Reported-by: "The UK's National Cyber Security Centre (NCSC)" <security@ncsc.gov.uk> Cc: stable <stable@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- net/packet/af_packet.c | 16 ++++++++-------- net/packet/internal.h | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-)