[PATCH] x25: validate class D facility length before reading it

Chuyf26 <[email protected]>
Newsgroups org.kernel.vger.netdev,org.kernel.vger.linux-x25
Message-ID <20260818162229.yOFI43Vfo0v911uVw0AFpyHQ_aOe_fsjoQXPZP70vMI@z>
x25_parse_facilities() checks that at least p[1] + 2 bytes remain for a
class D facility, but it reads p[1] itself to perform that check. If a
call setup packet carries a truncated facility list ending with a single
class D facility byte (len == 1), p[1] is dereferenced one byte past the
end of the facilities buffer.

The path is: a frame received over the LAPB link is handed to the X.25
state machine in x25_in.c, and call setup frames are parsed by
x25_parse_facilities(), called directly and via
x25_negotiate_facilities() for incoming calls, on the remaining skb
data. The facilities length is derived from the frame itself, so a peer
can deliver a list that ends exactly on the class D facility type byte.
The over-read lands one byte past the packet data but inside the skb
data allocation, where KASAN does not report it, and the value read
then controls how many further bytes the parser believes remain.

Classes A, B and C each validate their fixed length before reading any
value byte. Do the same for class D by requiring the two header bytes to
be present before p[1] is read.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Abaci <[email protected]>
Assisted-by: abaci:qwen3.8-max
Signed-off-by: Chuyf26 <[email protected]>
---
 net/x25/x25_facilities.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/x25/x25_facilities.c b/net/x25/x25_facilities.c
index 8e1a49b0c0dc..059dc3ac6261 100644
--- a/net/x25/x25_facilities.c
+++ b/net/x25/x25_facilities.c
@@ -147,7 +147,7 @@ int x25_parse_facilities(struct sk_buff *skb, struct x25_facilities *facilities,
 			len -= 4;
 			break;
 		case X25_FAC_CLASS_D:
-			if (len < p[1] + 2)
+			if (len < 2 || len < p[1] + 2)
 				return -1;
 			switch (*p) {
 			case X25_FAC_CALLING_AE:
-- 
2.43.5
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.