linux-kernel - Re: [PATCH v2 00/10] QRTR Multi-endpoint support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c7eeebdb-1ef5-4987-bf01-7890fb75e03b@ionic.de>
Date: Sun, 20 Jul 2025 12:54:34 +0200
From: Ionic <ionic@...ic.de>
To: linux-arm-msm@...r.kernel.org, Manivannan Sadhasivam <mani@...nel.org>
Cc: Eric Dumazet <edumazet@...gle.com>, Kuniyuki Iwashima
 <kuniyu@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Willem de Bruijn <willemb@...gle.com>, "David S . Miller"
 <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 Simon Horman <horms@...nel.org>, linux-kernel@...r.kernel.org,
 netdev@...r.kernel.org
Subject: Re: [PATCH v2 00/10] QRTR Multi-endpoint support

* On 7/19/25 20:59, Mihai Moldovan wrote:
> NOTE: There is 32-bit unsafe use of radix_tree_insert in this patch set.
> This follows the existing usage inside net/qrtr/af_qrtr.c in
> qrtr_tx_wait(), qrtr_tx_resume() and qrtr_tx_flow_failed().  This was
> done deliberately in order to keep the changes as minimal as possible
> until it is known whether the approach outlined is generally acceptable.

Since this is an actual problem and has to be eventually resolved, I'd like to 
ask for some guidance.

The Radix Tree API is fixed to using unsigned long keys, and my best idea (and 
the easiest thing to implement) thus far is to just go with that and restrict 
node IDs, endpoint IDs and port numbers to sizeof(unsigned long) / 2 bytes, 
which for platforms with 32-bit longs would be 16 bits. Not quite ideal, but 
probably good enough at the very least for port numbers (I figure).

Something like that:

#define RADIX_TREE_HALF_INDEX_BITS (RADIX_TREE_INDEX_BITS >> 1)
#define RADIX_TREE_HALF_INDEX_MAX_VALUE ((unsigned long)(-1) >> 
RADIX_TREE_HALF_INDEX_BITS)

with checks to make sure that node IDs, endpoint IDs and port numbers fit within 
RADIX_TREE_HALF_INDEX_MAX_VALUE.

Is this limitation acceptable? How big can node IDs get, also accounting for 
uncommon (and maybe also unrealistic) but conceivable use cases?

Mihai