netdev - Re: [ROSE] [AX25] 6.15.10 long term stable kernel oops

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: <4542b595-2398-4219-b643-4eda70a487f3@free.fr>
Date: Wed, 27 Aug 2025 16:16:31 +0200
From: F6BVP <f6bvp@...e.fr>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Dan Carpenter <dan.carpenter@...aro.org>, linux-hams@...r.kernel.org,
 netdev <netdev@...r.kernel.org>, Dan Cross <crossd@...il.com>,
 David Ranch <dranch@...nnet.net>,
 Folkert van Heusden <folkert@...heusden.com>
Subject: Re: [ROSE] [AX25] 6.15.10 long term stable kernel oops

Hi Eric,

I finally found the instruction triggering the bug in 
tty_ldisc_receive_buf()

Being absolutely new in kernel debugging, I read 
Documentation/admin-guide/bug-hunting.rst in order to see what I needed 
to do :
./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO

I also installed netconsole driver to capture Oops and received it on a 
local RaspBerry Pi with socat :
nohup socat -u udp-recv:6666 ./netconsole.log < /dev/null > /dev/null 2>&1 &

In function tty_ldisc_receive_buf() , call to receive_buf() goes well as 
long as count is small whereas with large number of bytes there is a 
kernel BUG NULL pointer dereference.

Included is the last netconsole log I captured and only kept last pages.

If with analyze netconsole.log from 4,19279,15377986 we see three 
sequences from tty_port_default_receive_buf to tty_ldisc_receive_buf 
giving the number of bytes processed.

If we concentrate on sequence __tty_insert_flip_string_flags that gives 
the number of copied bytes we see that just before the BUG something 
goes differently when bytes number is relatively high i.e. 272 in our case.
There is yet another tty_ldisc_deref after flush_to_ldisc and before 
receive_buf.

In netconsole.log (4,19284,1537778017) call to receive_buf() is fine 
with count value equal 18 bytes.

With line sequence (see below) 411, line 416, line 427 everything goes 
well when byte count is <=28 in our report.
On the contrary the sequence line 416, line 421, if bytes count is 
bigger (272), line 427 is not reached which means that

ld->ops->receive_buf(ld->tty, p, f, count);

never returns.

As a proof I commented this line of code and the BUG dissapeared... Of 
course the application did not achieved the AX25 connexion, waiting for 
a reply.

Here I am. Next step is probably to discover why the call to 
receive_buf() fails when bytes are not small and tty_ldisc_deref() is 
acting after flush_to_ldisc probably leading to an error. What value is 
wrong ? ld->tty , p, f ?

Regards,

Bernard

Here here tty_ldisc_receive_buf() with line numbers added to printk() lines:

size_t tty_ldisc_receive_buf(struct tty_ldisc *ld, const u8 *p, const u8 *f,
			     size_t count)
{

	if (ld->ops->receive_buf2)
	{
		count = ld->ops->receive_buf2(ld->tty, p, f, count);

L411		printk("Here I am: %s:%d count:%ld bytes 
buf2\n",__FUNCTION__,__LINE__,count);
	}
	else {
		count = min_t(size_t, count, ld->tty->receive_room);

L416		printk("Here I am: %s:%d count:%ld bytes tty 
receive_room\n",__FUNCTION__,__LINE__,count);

		if (count && ld->ops->receive_buf)
		{

L421			printk("Here I am: %s:%d count:%ld bytes ---> 
receive_buf\n",__FUNCTION__,__LINE__,count);

			ld->ops->receive_buf(ld->tty, p, f, count);
		}
	}

L427	printk("Here I am: %s:%d count:%ld bytes 
processed\n",__FUNCTION__,__LINE__,count);

	return count;
}
EXPORT_SYMBOL_GPL(tty_ldisc_receive_buf);

Le 26/08/2025 à 15:36, Eric Dumazet a écrit :
> 
> Make sure to add symbols to these logs, otherwise we can not really help.
> 
> cat CRASH | scripts/decode_stacktrace.sh ./vmlinux

View attachment "netconsole.log" of type "text/plain" (8519 bytes)