| 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
| ||
|
Message-ID: <2025050821-CVE-2025-37824-61fa@gregkh>
Date: Thu, 8 May 2025 08:39:33 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-37824: tipc: fix NULL pointer dereference in tipc_mon_reinit_self()
From: Greg Kroah-Hartman <gregkh@...nel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix NULL pointer dereference in tipc_mon_reinit_self()
syzbot reported:
tipc: Node number set to 1055423674
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: events tipc_net_finalize_work
RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719
...
RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba
RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010
RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007
R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010
FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140
process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238
process_scheduled_works kernel/workqueue.c:3319 [inline]
worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400
kthread+0x3c2/0x780 kernel/kthread.c:464
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
...
RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719
...
RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba
RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010
RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007
R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010
FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
There is a racing condition between workqueue created when enabling
bearer and another thread created when disabling bearer right after
that as follow:
enabling_bearer | disabling_bearer
--------------- | ----------------
tipc_disc_timeout() |
{ | bearer_disable()
... | {
schedule_work(&tn->work); | tipc_mon_delete()
... | {
} | ...
| write_lock_bh(&mon->lock);
| mon->self = NULL;
| write_unlock_bh(&mon->lock);
| ...
| }
tipc_net_finalize_work() | }
{ |
... |
tipc_net_finalize() |
{ |
... |
tipc_mon_reinit_self() |
{ |
... |
write_lock_bh(&mon->lock); |
mon->self->addr = tipc_own_addr(net); |
write_unlock_bh(&mon->lock); |
... |
} |
... |
} |
... |
} |
'mon->self' is set to NULL in disabling_bearer thread and dereferenced
later in enabling_bearer thread.
This commit fixes this issue by validating 'mon->self' before assigning
node address to it.
The Linux kernel CVE team has assigned CVE-2025-37824 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.4.15 with commit 28845c28f842e9e55e75b2c116bff714bb039055 and fixed in 5.4.293 with commit a3df56010403b2cd26388096ebccf959d23c4dcc
Issue introduced in 5.5 with commit 46cb01eeeb86fca6afe24dda1167b0cb95424e29 and fixed in 5.10.237 with commit e6613b6d41f4010c4d484cbc7bfca690d8d522a2
Issue introduced in 5.5 with commit 46cb01eeeb86fca6afe24dda1167b0cb95424e29 and fixed in 5.15.181 with commit 5fd464fd24de93d0eca377554bf0ff2548f76f30
Issue introduced in 5.5 with commit 46cb01eeeb86fca6afe24dda1167b0cb95424e29 and fixed in 6.1.136 with commit e79e8e05aa46f90d21023f0ffe6f136ed6a20932
Issue introduced in 5.5 with commit 46cb01eeeb86fca6afe24dda1167b0cb95424e29 and fixed in 6.6.89 with commit dd6cb0a8575b00fbd503e96903184125176f4fa3
Issue introduced in 5.5 with commit 46cb01eeeb86fca6afe24dda1167b0cb95424e29 and fixed in 6.12.26 with commit 0ceef62a328ce1288598c9242576292671f21e96
Issue introduced in 5.5 with commit 46cb01eeeb86fca6afe24dda1167b0cb95424e29 and fixed in 6.14.5 with commit 4d5e1e2d3e9d70beff7beab44fd6ce91405a405e
Issue introduced in 5.5 with commit 46cb01eeeb86fca6afe24dda1167b0cb95424e29 and fixed in 6.15-rc4 with commit d63527e109e811ef11abb1c2985048fdb528b4cb
Issue introduced in 4.19.99 with commit 295c9b554f6dfcd2d368fae6e6fa22ee5b79c123
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2025-37824
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
net/tipc/monitor.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/a3df56010403b2cd26388096ebccf959d23c4dcc
https://git.kernel.org/stable/c/e6613b6d41f4010c4d484cbc7bfca690d8d522a2
https://git.kernel.org/stable/c/5fd464fd24de93d0eca377554bf0ff2548f76f30
https://git.kernel.org/stable/c/e79e8e05aa46f90d21023f0ffe6f136ed6a20932
https://git.kernel.org/stable/c/dd6cb0a8575b00fbd503e96903184125176f4fa3
https://git.kernel.org/stable/c/0ceef62a328ce1288598c9242576292671f21e96
https://git.kernel.org/stable/c/4d5e1e2d3e9d70beff7beab44fd6ce91405a405e
https://git.kernel.org/stable/c/d63527e109e811ef11abb1c2985048fdb528b4cb
Powered by blists - more mailing lists