Re: [PATCH v4 net] net: ax25: fix integer overflow in ax25_rx_fragment()

Hi Paolo, All,

On 21/4/2026 17:29, Paolo Abeni wrote:
> On 4/13/26 10:49 PM, Mashiro Chen wrote:
>> ax25_rx_fragment() accumulates fragment lengths into ax25_cb->fraglen,
>> which is an unsigned short. When the total exceeds 65535, fraglen wraps
>> around to a small value. The subsequent alloc_skb(fraglen) allocates a
>> too-small buffer, and skb_put() in the copy loop triggers skb_over_panic().
>>
>> Add pskb_may_pull(skb, 1) at function entry to ensure the segmentation
>> header byte is in the linear data area before dereferencing skb->data.
>> This also rejects zero-length skbs, which the original code did not
>> check for.
>>
>> Two issues in the overflow error path are also fixed:
>> First, the current skb, after skb_pull(skb, 1), is neither enqueued
>> nor freed before returning 1, leaking it. Add kfree_skb(skb) before
>> the return.
>> Second, ax25->fraglen is not reset after skb_queue_purge(). Add
>> ax25->fraglen = 0 to restore a consistent state.
>>
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> Signed-off-by: Mashiro Chen <[email protected]>
> we are moving ax25 out of tree:
>
> https://lore.kernel.org/netdev/[email protected]/
>
> please hold off until Thursday (after that our net PR will land into
> mainline), and eventually resend if the code still exists in Linus's
> tree at that point.

Is there any flexibility here ?

Jakubs (CC'd) patches to remove unfortunately weren't cross posted to 
linux-hams and so I'm not able to directly reply in netdev

We've had a thread ongoing in linux-hams around the future of 
AX25/ROSE/NETROM for the last week or so and believe we've a path 
towards an orderly exit from the mainline tree, probably towards a 
userspace implementation. This includes a couple of folks who have 
indicated they would be open to overseeing the maintenance of the code 
in the meantime.

We'd hoped to have a period of a few months to do an orderly exit from 
the tree to minimise the impact on the (admittedly small, but non-zero) 
users that build trees/make use of the in kernel support.

Apologies for my lack of familiarity with the process here to deprecate etc.

Cheers/73
Hugh


-- 
I am slowly moving to [email protected] as my main email address.
If you're using [email protected] please update your address book accordingly.
Thank you :)