Message-ID: <6a5cf9cf-9984-4e1b-882f-b9b427d3c096@free.fr>
Date: Sun, 24 Aug 2025 16:04:40 +0200
From: F6BVP <f6bvp@...e.fr>
To: linux-hams@...r.kernel.org, netdev <netdev@...r.kernel.org>
Cc: Dan Cross <crossd@...il.com>, David Ranch <dranch@...nnet.net>,
 Eric Dumazet <edumazet@...gle.com>,
 Folkert van Heusden <folkert@...heusden.com>
Subject: Re: [ROSE] [AX25] 6.15.10 long term stable kernel oops

Hi All,

I suspect I finally found the bug that triggered a kernel panic since 
linux-15.1 version up to net-next.

Actually I found a report from

syzbot+dca31068cff20d2ad44d@...kaller.appspotmail.com

that directed me to the solution.

A pointer *p to a buffer was declared in tty_buffer_alloc() buf not 
initialized.

Explanation :
- Sometime AX25 can perform connexions via a kissattached Ethernet port.
- In that case when an application sends a connect request from a 
console, tty_port is used by mkiss.

All kernel panic reports I sent earlier show that mkiss_receive_buf was 
involved together with tty_port_default and tty_ldisc_receive_buf.

It was sysbot detailed reporting KMSAN uninit value in mkiss_receive_buf 
that led me to the solution. Although it took me a while to understand 
the report for this is totally new for me...

Looking at the code I found :

static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t 
size)
  {
  	struct llist_node *free;
	struct tty_buffer *p;

I first introduced a call to kmalloc in order to initialize pointer p 
like it is done elsewhere in the function.

This performed well and Oops disappeared.

Then I tried to first initialize *p to NULL when it is declared :

struct tty_buffer *p=NULL;

When added it also performed correctly.

And finally I removed the kmalloc early instruction and only kept the 
*p=NULL initialization.

Since then, I checked this simple initialization on both 6.15.2 and 
6.17-rc2 and there was no more Oops.

I will provide the following patch against net-next in due form if there 
is no objection.

diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 67271fc0b223..33e7f675b06d 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -159,7 +159,7 @@ void tty_buffer_free_all(struct tty_port *port)
  static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, 
size_t size)
  {
  	struct llist_node *free;
-	struct tty_buffer *p;
+	struct tty_buffer *p=NULL;

  	/* Round the buffer size out */
  	size = __ALIGN_MASK(size, TTYB_ALIGN_MASK);


Bernard


Le 22/08/2025 à 05:10, Folkert van Heusden a écrit :
> Bernard,
> 
> I skimmed over the diff between the latest 6.14.y and latest 6.15.y tags 
> of the raspberry pi linux kernel and didn't saw anything relevant 
> changed. Altough changes in 'arch' could in theory affect everything.
> 
> 
> On 2025-08-22 00:39, F6BVP wrote:
>> As I already reported mkiss never triggered any Oops kernel panic up 
>> to linux-6.14.11.
>>
>> In that version I put a number of printk inside of mkiss.c in order to 
>> follow the normal behaviour and content outside and during FPAC 
>> functionning especially when issuing a connect request.
>>
>> On the opposite an FPAC connect request systematically triggers a 
>> kernel panic with linux-6.15.2 and following kernels.
>>
>> In 6.14.11 I observe that when mkiss runs core/dev is never activated 
>> i.e. neither __netif_receive_skb nor __netif_receive_skb_one_core.
>>
>> These functions appear in kernel 6.15.2 panics after mkiss_receive_buf.
>>
>> One can guess that mkiss_receive_buf() is triggering something wrong 
>> in kernel 6.15.2 and all following kernels up to net-next.
>>
>> The challenge to locate the bug is quite difficult as I did not find 
>> the way to find relevant code differences between both kernels in 
>> absence of inc patch...
>>
>> I sincerely regret not knowing how to go further.
>>
>> Bernard,
>> hamradio f6bvp /ai7bg
> 

Powered by blists - more mailing lists