netdev - Re: [PATCH net v2] netrom: fix out-of-bounds read in nr_rx

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: <CANn89i+xUZ5R1jV8O8u6WpX1RDtgtdcfUHVGDrVZFuO7fuXrbg@mail.gmail.com>
Date: Tue, 2 Sep 2025 05:17:00 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Stanislav Fort <stanislav.fort@...le.com>
Cc: netdev@...r.kernel.org, kuba@...nel.org, security@...nel.org, 
	Stanislav Fort <disclosure@...le.com>
Subject: Re: [PATCH net v2] netrom: fix out-of-bounds read in nr_rx_frame()

On Tue, Sep 2, 2025 at 4:27 AM Stanislav Fort <stanislav.fort@...le.com> wrote:
>
> Add early pskb_may_pull() validation in nr_rx_frame() to prevent
> out-of-bounds reads when processing malformed NET/ROM frames.
>
> The vulnerability occurs when nr_route_frame() accepts frames as
> short as NR_NETWORK_LEN (15 bytes) but nr_rx_frame() immediately
> accesses the 5-byte transport header at bytes 15-19 without validation.
> For CONNREQ frames, additional fields are accessed (window at byte 20,
> user address at bytes 21-27, optional BPQ timeout at bytes 35-36).
>
> Attack vector: External AX.25 I-frames with PID=0xCF (NET/ROM) can
> reach nr_route_frame() via the AX.25 protocol dispatch mechanism:
>   ax25_rcv() -> ax25_rx_iframe() -> ax25_protocol_function(0xCF)
>   -> nr_route_frame()
>
> For frames destined to local NET/ROM devices, nr_route_frame() calls
> nr_rx_frame() which immediately dereferences unvalidated offsets,
> causing out-of-bounds reads that can crash the kernel or leak memory.
>
> Fix by using pskb_may_pull() early to linearize the maximum required
> packet size (37 bytes) before any pointer assignments. This prevents
> use-after-free issues when pskb_may_pull() reallocates skb->head and
> ensures all subsequent accesses are within bounds.
>
> Reported-by: Stanislav Fort <disclosure@...le.com>
> Signed-off-by: Stanislav Fort <disclosure@...le.com>
> ---
>  net/netrom/af_netrom.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
> index 3331669d8e33..3056229dcd20 100644
> --- a/net/netrom/af_netrom.c
> +++ b/net/netrom/af_netrom.c
> @@ -883,7 +883,11 @@ int nr_rx_frame(struct sk_buff *skb, struct net_device *dev)
>
>         /*
>          *      skb->data points to the netrom frame start
> +        *      Linearize the packet early to avoid use-after-free issues
> +        *      when pskb_may_pull() reallocates skb->head later
>          */
> +       if (!pskb_may_pull(skb, max(NR_NETWORK_LEN + NR_TRANSPORT_LEN + 1 + AX25_ADDR_LEN, 37)))
> +               return 0;

I am not sure about the minimal packet length we expect from this point.

I was suggesting to use skb_linearize() here, but then add the needed
skb->len checks
of various sizes depending on the context (different places you had
patched earlier)

Thank you.