netdev - Re: [PATCH net] netrom: fix info-leak in nr_write

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZG8R3uaruTpe38pZ@corigine.com>
Date: Thu, 25 May 2023 09:44:30 +0200
From: Simon Horman <simon.horman@...igine.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, eric.dumazet@...il.com,
	Simon Kapadia <szymon@...adia.pl>
Subject: Re: [PATCH net] netrom: fix info-leak in nr_write_internal()

On Wed, May 24, 2023 at 02:14:56PM +0000, Eric Dumazet wrote:
> Simon Kapadia reported the following issue:
> 
> <quote>
> 
> The Online Amateur Radio Community (OARC) has recently been experimenting
> with building a nationwide packet network in the UK.
> As part of our experimentation, we have been testing out packet on 300bps HF,
> and playing with net/rom.  For HF packet at this baud rate you really need
> to make sure that your MTU is relatively low; AX.25 suggests a PACLEN of 60,
> and a net/rom PACLEN of 40 to go with that.
> However the Linux net/rom support didn't work with a low PACLEN;
> the mkiss module would truncate packets if you set the PACLEN below about 200 or so, e.g.:
> 
> Apr 19 14:00:51 radio kernel: [12985.747310] mkiss: ax1: truncating oversized transmit packet!
> 
> This didn't make any sense to me (if the packets are smaller why would they
> be truncated?) so I started investigating.
> I looked at the packets using ethereal, and found that many were just huge
> compared to what I would expect.
> A simple net/rom connection request packet had the request and then a bunch
> of what appeared to be random data following it:
> 
> </quote>
> 
> Simon provided a patch that I slightly revised:
> Not only we must not use skb_tailroom(), we also do
> not want to count NR_NETWORK_LEN twice.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Co-Developed-by: Simon Kapadia <szymon@...adia.pl>
> Signed-off-by: Simon Kapadia <szymon@...adia.pl>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Tested-by: Simon Kapadia <szymon@...adia.pl>

Reviewed-by: Simon Horman <simon.horman@...igine.com>