Thread (11 messages) 11 messages, 3 authors, 2025-10-28

Re: [PATCH V3] net: rose: Prevent the use of freed digipeat

From: Kuniyuki Iwashima <kuniyu@google.com>
Date: 2025-10-25 07:16:03
Also in: linux-hams, lkml

On Fri, Oct 24, 2025 at 11:46 PM Lizhi Xu [off-list ref] wrote:
On Fri, 24 Oct 2025 21:25:20 -0700, Kuniyuki Iwashima [off-list ref] wrote:
quoted
On Fri, Oct 24, 2025 at 8:51 PM Lizhi Xu [off-list ref] wrote:
quoted
On Fri, 24 Oct 2025 19:18:46 -0700, Kuniyuki Iwashima [off-list ref] wrote:
quoted
On Fri, Oct 24, 2025 at 2:39 AM Lizhi Xu [off-list ref] wrote:
quoted
There is no synchronization between the two timers, rose_t0timer_expiry
and rose_timer_expiry.
rose_timer_expiry() puts the neighbor when the rose state is ROSE_STATE_2.
However, rose_t0timer_expiry() does initiate a restart request on the
neighbor.
When rose_t0timer_expiry() accesses the released neighbor member digipeat,
a UAF is triggered.

To avoid this UAF, defer the put operation to rose_t0timer_expiry() and
stop restarting t0timer after putting the neighbor.

When putting the neighbor, set the neighbor to NULL. Setting neighbor to
NULL prevents rose_t0timer_expiry() from restarting t0timer.

syzbot reported a slab-use-after-free Read in ax25_find_cb.
BUG: KASAN: slab-use-after-free in ax25_find_cb+0x3b8/0x3f0 net/ax25/af_ax25.c:237
Read of size 1 at addr ffff888059c704c0 by task syz.6.2733/17200
Call Trace:
 ax25_find_cb+0x3b8/0x3f0 net/ax25/af_ax25.c:237
 ax25_send_frame+0x157/0xb60 net/ax25/ax25_out.c:55
 rose_send_frame+0xcc/0x2c0 net/rose/rose_link.c:106
 rose_transmit_restart_request+0x1b8/0x240 net/rose/rose_link.c:198
 rose_t0timer_expiry+0x1d/0x150 net/rose/rose_link.c:83

Freed by task 17183:
 kfree+0x2b8/0x6d0 mm/slub.c:6826
 rose_neigh_put include/net/rose.h:165 [inline]
 rose_timer_expiry+0x537/0x630 net/rose/rose_timer.c:183

Fixes: d860d1faa6b2 ("net: rose: convert 'use' field to refcount_t")
Reported-by: syzbot+caa052a0958a9146870d@syzkaller.appspotmail.com
Signed-off-by: Lizhi Xu <redacted>
---
V1 -> V2: Putting the neighbor stops t0timer from automatically starting
V2 -> V3: add rose_neigh_putex for set rose neigh to NULL

 include/net/rose.h   | 12 ++++++++++++
 net/rose/rose_link.c |  5 +++++
 2 files changed, 17 insertions(+)
diff --git a/include/net/rose.h b/include/net/rose.h
index 2b5491bbf39a..33de310ba778 100644
--- a/include/net/rose.h
+++ b/include/net/rose.h
@@ -167,6 +167,18 @@ static inline void rose_neigh_put(struct rose_neigh *rose_neigh)
        }
 }

+static inline void rose_neigh_putex(struct rose_neigh **roseneigh)
+{
+       struct rose_neigh *rose_neigh = *roseneigh;
+       if (refcount_dec_and_test(&rose_neigh->use)) {
+               if (rose_neigh->ax25)
+                       ax25_cb_put(rose_neigh->ax25);
+               kfree(rose_neigh->digipeat);
+               kfree(rose_neigh);
+               *roseneigh = NULL;
+       }
+}
+
 /* af_rose.c */
 extern ax25_address rose_callsign;
 extern int  sysctl_rose_restart_request_timeout;
diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
index 7746229fdc8c..334c8cc0876d 100644
--- a/net/rose/rose_link.c
+++ b/net/rose/rose_link.c
@@ -43,6 +43,9 @@ void rose_start_ftimer(struct rose_neigh *neigh)

 static void rose_start_t0timer(struct rose_neigh *neigh)
 {
+       if (!neigh)
+               return;
+
        timer_delete(&neigh->t0timer);

        neigh->t0timer.function = rose_t0timer_expiry;
@@ -80,10 +83,12 @@ static void rose_t0timer_expiry(struct timer_list *t)
 {
        struct rose_neigh *neigh = timer_container_of(neigh, t, t0timer);
What prevents rose_timer_expiry() from releasing the
last refcnt here ?
The issue reported by syzbot is that rose_t0timer_expiry() is triggered
first, followed by rose_timer_expiry().
I don't see how you read that ordering from the report.
https://syzkaller.appspot.com/bug?extid=caa052a0958a9146870d
Here's my understanding: See the two calltraces below.
The same question still applies.

What prevents rose_timer_expiry() from releasing the last
refcnt before [1] ?

For example, why is accessing neigh->dev in rose_send_frame()
safe then ?

The commit message mentions that two timers are not
synchronised, but the diff adds no such synchronisation.

[1] Line 111 occurs after rose_neigh_put(). Otherwise, accessing
neigh->digipeat would result in a UAF. Therefore, rose_t0timer_expiry()
must be triggered before rose_timer_expiry().

[2] syzbot reports that line 237 generates a UAF when accessing digi->ndigi.

UAF Task1:
rose_t0timer_expiry()->
  rose_transmit_restart_request()->
    rose_send_frame(.., neigh->digipeat, ..)-> // [1] line 111
      ax25_find_cb()->
        if (digi != NULL && digi->ndigi != 0)  // [2] line 237

Freed neigh Task2:
 rose_timer_expiry()->
   rose_neigh_put(neigh)->
     kfree(neigh)
quoted
The only ordering I can find is that kfree() in rose_timer_expiry()
happened before ax25_find_cb () in rose_t0timer_expiry().
quoted
Therefore, in rose_t0timer_expiry(), the reference count of neigh is
increased before entering rose_transmit_restart_request() to prevent
neigh from being put in rose_timer_expiry(). Then, in rose_t0timer_expiry(),
neigh is put before executing rose_start_t0timer() and the neigh value is
set to NULL to prevent t0timer restarts.

The case where rose_timer_expiry() is triggered before rose_t0timer_expiry()
is not considered at this time.
So this change just papers over the root cause.

quoted
quoted
The t0timer could be triggered even after that happens.

quoted
+       rose_neigh_hold(neigh);
        rose_transmit_restart_request(neigh);

        neigh->dce_mode = 0;

+       rose_neigh_putex(&neigh);
        rose_start_t0timer(neigh);
 }

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