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@syzkaller.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:

quoted

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