Thread (26 messages) 26 messages, 9 authors, 2025-09-02

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

From: F6BVP <hidden>
Date: 2025-08-27 14:16:47
Also in: linux-hams

Possibly related (same subject, not in this thread)

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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help