Current code does no bound checking on the number of lookups a client can
perform per socket. Though the code restricts the lookups to local clients,
there is still a possibility of a malicious local client sending a flood of
NEW_LOOKUP messages over the same socket.

Fix this issue by limiting the maximum number of lookups to 64 per socket.
Note that, limit of 64 is chosen based on the current platform
requirements. If requirement changes in the future, this limit can be
increased.

Cc: stable@vger.kernel.org
Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 net/qrtr/ns.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
index fb4e8a2d370d..707fde809939 100644
--- a/net/qrtr/ns.c
+++ b/net/qrtr/ns.c
@@ -70,10 +70,11 @@ struct qrtr_node {
 	u32 server_count;
 };
 
-/* Max server limit is chosen based on the current platform requirements. If the
- * requirement changes in the future, this value can be increased.
+/* Max server, lookup limits are chosen based on the current platform requirements.
+ * If the requirement changes in the future, these values can be increased.
  */
 #define QRTR_NS_MAX_SERVERS 256
+#define QRTR_NS_MAX_LOOKUPS 64
 
 static struct qrtr_node *node_get(unsigned int node_id)
 {
@@ -545,11 +546,24 @@ static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from,
 	struct qrtr_node *node;
 	unsigned long node_idx;
 	unsigned long srv_idx;
+	u8 count = 0;
 
 	/* Accept only local observers */
 	if (from->sq_node != qrtr_ns.local_node)
 		return -EINVAL;
 
+	/* Make sure the client performs only maximum allowed lookups */
+	list_for_each_entry(lookup, &qrtr_ns.lookups, li) {
+		if (lookup->sq.sq_node == from->sq_node &&
+		    lookup->sq.sq_port == from->sq_port)
+			count++;
+	}
+
+	if (count >= QRTR_NS_MAX_LOOKUPS) {
+		pr_err_ratelimited("QRTR client node exceeds max lookup limit!\n");
+		return -ENOSPC;
+	}
+
 	lookup = kzalloc_obj(*lookup);
 	if (!lookup)
 		return -ENOMEM;
-- 
2.51.0

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: qrtr: ns: Limit the maximum lookups per socket

This commit limits the maximum number of lookups to 64 per socket to prevent
a malicious local client from sending a flood of NEW_LOOKUP messages over the
same socket.

> diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
> index fb4e8a2d370d..707fde809939 100644
> --- a/net/qrtr/ns.c
> +++ b/net/qrtr/ns.c

[ ... ]

> @@ -545,11 +546,24 @@ static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from,
>  	struct qrtr_node *node;
>  	unsigned long node_idx;
>  	unsigned long srv_idx;
> +	u8 count = 0;
>  
>  	/* Accept only local observers */
>  	if (from->sq_node != qrtr_ns.local_node)
>  		return -EINVAL;
>  
> +	/* Make sure the client performs only maximum allowed lookups */
> +	list_for_each_entry(lookup, &qrtr_ns.lookups, li) {
> +		if (lookup->sq.sq_node == from->sq_node &&
> +		    lookup->sq.sq_port == from->sq_port)
> +			count++;
> +	}

Does this O(N) traversal of the global qrtr_ns.lookups list create a CPU
exhaustion issue?

If a local attacker opens many sockets and registers the maximum 64 lookups
on each, the global list could grow to tens of thousands of items.

If the attacker then floods the socket with NEW_LOOKUP packets, the
single-threaded qrtr_ns.workqueue worker would be forced to traverse all
elements for every packet, potentially blocking all legitimate QRTR namespace
control traffic.

> +
> +	if (count >= QRTR_NS_MAX_LOOKUPS) {
> +		pr_err_ratelimited("QRTR client node exceeds max lookup limit!\n");
> +		return -ENOSPC;

Does returning -ENOSPC here defeat the ratelimiting?

If the caller qrtr_ns_worker() unconditionally checks for a negative return
value and executes an unratelimited error print, a malicious local client
could still cause a syslog flood by sending continuous NEW_LOOKUP packets
after hitting the limit.

Should this return 0 instead to avoid the unratelimited print in the caller?

> +	}
> +
>  	lookup = kzalloc_obj(*lookup);
>  	if (!lookup)
>  		return -ENOMEM;

This isn't a regression introduced by this patch, but does qrtr_ns_remove()
contain a use-after-free during module unload?

The teardown sequence appears to be:
1. cancel_work_sync()
2. destroy_workqueue(qrtr_ns.workqueue)
3. sock_release(qrtr_ns.sock)

If a packet arrives between destroy_workqueue() and sock_release(), the
socket's receive path triggers qrtr_ns_data_ready(). This callback calls
queue_work(qrtr_ns.workqueue, ...), which dereferences the already-freed
workqueue pointer.

Should the socket be shut down or the callback disabled before destroying
the workqueue?

On Wed, Mar 25, 2026 at 04:14:15PM +0530, Manivannan Sadhasivam wrote:
> Current code does no bound checking on the number of lookups a client can
> perform per socket. Though the code restricts the lookups to local clients,
> there is still a possibility of a malicious local client sending a flood of
> NEW_LOOKUP messages over the same socket.
> 
> Fix this issue by limiting the maximum number of lookups to 64 per socket.
> Note that, limit of 64 is chosen based on the current platform
> requirements. If requirement changes in the future, this limit can be
> increased.
> 
> Cc: stable@vger.kernel.org
> Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  net/qrtr/ns.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
> index fb4e8a2d370d..707fde809939 100644
> --- a/net/qrtr/ns.c
> +++ b/net/qrtr/ns.c
> @@ -70,10 +70,11 @@ struct qrtr_node {
>  	u32 server_count;
>  };
>  
> -/* Max server limit is chosen based on the current platform requirements. If the
> - * requirement changes in the future, this value can be increased.
> +/* Max server, lookup limits are chosen based on the current platform requirements.
> + * If the requirement changes in the future, these values can be increased.
>   */
>  #define QRTR_NS_MAX_SERVERS 256
> +#define QRTR_NS_MAX_LOOKUPS 64
>  
>  static struct qrtr_node *node_get(unsigned int node_id)
>  {
> @@ -545,11 +546,24 @@ static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from,
>  	struct qrtr_node *node;
>  	unsigned long node_idx;
>  	unsigned long srv_idx;
> +	u8 count = 0;
>  
>  	/* Accept only local observers */
>  	if (from->sq_node != qrtr_ns.local_node)
>  		return -EINVAL;
>  
> +	/* Make sure the client performs only maximum allowed lookups */
> +	list_for_each_entry(lookup, &qrtr_ns.lookups, li) {
> +		if (lookup->sq.sq_node == from->sq_node &&
> +		    lookup->sq.sq_port == from->sq_port)
> +			count++;

This feels like it could get quite expensive.
If many lookups are added, it feels like it may be O(n^2).

Is this something that has been considered?

> +	}
> +
> +	if (count >= QRTR_NS_MAX_LOOKUPS) {
> +		pr_err_ratelimited("QRTR client node exceeds max lookup limit!\n");
> +		return -ENOSPC;
> +	}
> +
>  	lookup = kzalloc_obj(*lookup);
>  	if (!lookup)
>  		return -ENOMEM;
> -- 
> 2.51.0
>

On Fri, Mar 27, 2026 at 10:07:09AM +0000, Simon Horman wrote:
> On Wed, Mar 25, 2026 at 04:14:15PM +0530, Manivannan Sadhasivam wrote:
> > Current code does no bound checking on the number of lookups a client can
> > perform per socket. Though the code restricts the lookups to local clients,
> > there is still a possibility of a malicious local client sending a flood of
> > NEW_LOOKUP messages over the same socket.
> > 
> > Fix this issue by limiting the maximum number of lookups to 64 per socket.
> > Note that, limit of 64 is chosen based on the current platform
> > requirements. If requirement changes in the future, this limit can be
> > increased.
> > 
> > Cc: stable@vger.kernel.org
> > Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > ---
> >  net/qrtr/ns.c | 18 ++++++++++++++++--
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
> > index fb4e8a2d370d..707fde809939 100644
> > --- a/net/qrtr/ns.c
> > +++ b/net/qrtr/ns.c
> > @@ -70,10 +70,11 @@ struct qrtr_node {
> >  	u32 server_count;
> >  };
> >  
> > -/* Max server limit is chosen based on the current platform requirements. If the
> > - * requirement changes in the future, this value can be increased.
> > +/* Max server, lookup limits are chosen based on the current platform requirements.
> > + * If the requirement changes in the future, these values can be increased.
> >   */
> >  #define QRTR_NS_MAX_SERVERS 256
> > +#define QRTR_NS_MAX_LOOKUPS 64
> >  
> >  static struct qrtr_node *node_get(unsigned int node_id)
> >  {
> > @@ -545,11 +546,24 @@ static int ctrl_cmd_new_lookup(struct sockaddr_qrtr *from,
> >  	struct qrtr_node *node;
> >  	unsigned long node_idx;
> >  	unsigned long srv_idx;
> > +	u8 count = 0;
> >  
> >  	/* Accept only local observers */
> >  	if (from->sq_node != qrtr_ns.local_node)
> >  		return -EINVAL;
> >  
> > +	/* Make sure the client performs only maximum allowed lookups */
> > +	list_for_each_entry(lookup, &qrtr_ns.lookups, li) {
> > +		if (lookup->sq.sq_node == from->sq_node &&
> > +		    lookup->sq.sq_port == from->sq_port)
> > +			count++;
> 
> This feels like it could get quite expensive.
> If many lookups are added, it feels like it may be O(n^2).
> 

Lookups are not something that'll happen very often. A client only registers
for the lookup once per service that it depends on. That shouldn't be too
much. And then once lookup is registered, it will be used throughout the
lifetime of the client.

So there is no overhead associated with this check.

- Mani

-- 
மணிவண்ணன் சதாசிவம்