Commit 2835750dd647 ("net: rose: reject truncated CLEAR_REQUEST frames
in state machines") guards against short CLEAR_REQUEST frames using a
plain skb->len comparison. Use pskb_may_pull() instead, which both
enforces the length requirement and ensures the bytes are in the linear
part of the skb, making the subsequent accesses to skb->data[3] and
skb->data[4] safe for non-linear buffers.

Suggested-by: Simon Horman <horms@kernel.org>
Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
---
 net/rose/rose_in.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rose/rose_in.c b/net/rose/rose_in.c
index ca4f217ef3d3..48183363d3f9 100644
--- a/net/rose/rose_in.c
+++ b/net/rose/rose_in.c
@@ -274,7 +274,7 @@ int rose_process_rx_frame(struct sock *sk, struct sk_buff *skb)
 	 * ROSE_CLEAR_REQUEST carries cause and diagnostic in bytes 3..4.
 	 * Reject a malformed frame that is too short to contain them.
 	 */
-	if (frametype == ROSE_CLEAR_REQUEST && skb->len < 5)
+	if (frametype == ROSE_CLEAR_REQUEST && !pskb_may_pull(skb, 5))
 		return 0;
 
 	switch (rose->state) {
-- 
2.34.1

On Mon, Apr 20, 2026 at 01:57:23AM +0000, Ashutosh Desai wrote:
> Commit 2835750dd647 ("net: rose: reject truncated CLEAR_REQUEST frames
> in state machines") guards against short CLEAR_REQUEST frames using a
> plain skb->len comparison. Use pskb_may_pull() instead, which both
> enforces the length requirement and ensures the bytes are in the linear
> part of the skb, making the subsequent accesses to skb->data[3] and
> skb->data[4] safe for non-linear buffers.

Did you review all the other comparisons on skb->len in rose?

rose_route.c-	if (frametype == ROSE_CALL_REQUEST &&
rose_route.c:	    (skb->len <= ROSE_CALL_REQ_FACILITIES_OFF ||
rose_route.c-	     skb->data[ROSE_CALL_REQ_ADDR_LEN_OFF] !=
rose_route.c-	     ROSE_CALL_REQ_ADDR_LEN_VAL))

rose_loopback.c-		if (frametype == ROSE_CALL_REQUEST &&
rose_loopback.c:		    (skb->len <= ROSE_CALL_REQ_FACILITIES_OFF ||
rose_loopback.c-		     skb->data[ROSE_CALL_REQ_ADDR_LEN_OFF] !=

Do these need the same fix? Are there other places non linear buffers
should be considered?

       Andrew

On Mon, Apr 20, 2026 at 15:04:30 +0200, Andrew Lunn wrote:
> Did you review all the other comparisons on skb->len in rose?
> Do these need the same fix? Are there other places non linear buffers
> should be considered?

Reviewed all rose files. Thanks for pointing those out - yes, the two
spots in rose_route.c and rose_loopback.c have the same issue and need
the same fix.

While reviewing I also noticed rose_link.c: rose_link_rx_restart()
accesses skb->data[3] in the ROSE_RESTART_REQUEST case and
skb->data[3]/skb->data+4 in the ROSE_DIAGNOSTIC case, with only a
ROSE_MIN_LEN (3 bytes) guard upstream in the caller. Same linearity
concern.

Is it recommended to send a v2 covering all three files?

On Tue, Apr 21, 2026 at 02:27:12AM +0000, Ashutosh Desai wrote:
> On Mon, Apr 20, 2026 at 15:04:30 +0200, Andrew Lunn wrote:
> > Did you review all the other comparisons on skb->len in rose?
> > Do these need the same fix? Are there other places non linear buffers
> > should be considered?
> 
> Reviewed all rose files. Thanks for pointing those out - yes, the two
> spots in rose_route.c and rose_loopback.c have the same issue and need
> the same fix.
> 
> While reviewing I also noticed rose_link.c: rose_link_rx_restart()
> accesses skb->data[3] in the ROSE_RESTART_REQUEST case and
> skb->data[3]/skb->data+4 in the ROSE_DIAGNOSTIC case, with only a
> ROSE_MIN_LEN (3 bytes) guard upstream in the caller. Same linearity
> concern.
> 
> Is it recommended to send a v2 covering all three files?

Too late, Jakub just posted patches deleted it all. See the netdev
mailing list.

    Andrew