[PATCH net] net/packet: move reference count in packet_sock to 64 bits

[PATCH net] net/packet: move reference count in packet_sock to 64 bits

[Greg Kroah-Hartman]

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(-)

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;
-- 
2.43.0

Re: [PATCH net] net/packet: move reference count in packet_sock to 64 bits

[Daniel Borkmann]

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>

Re: [PATCH net] net/packet: move reference count in packet_sock to 64 bits

[Willem de Bruijn]

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>

Re: [PATCH net] net/packet: move reference count in packet_sock to 64 bits

[Daniel Borkmann]

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

Re: [PATCH net] net/packet: move reference count in packet_sock to 64 bits

[Greg Kroah-Hartman]

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