* [syzbot] KASAN: slab-use-after-free Write in o2hb_region_dev_store
@ 2026-09-04 22:00 syzbot
2026-09-04 23:35 ` Forwarded: [PATCH] ocfs2: fix use-after-free " syzbot
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: syzbot @ 2026-09-04 22:00 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: bc35965f6940 Merge tag 'mm-hotfixes-stable-2026-09-03-17-4..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=119c84f9580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8c5c3949d762a91f
dashboard link: https://syzkaller.appspot.com/bug?extid=3025e3e8fc0b928af8f5
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1714a8f9580000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3025e3e8fc0b928af8f5@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in o2hb_map_slot_data fs/ocfs2/cluster/heartbeat.c:1811 [inline]
BUG: KASAN: slab-use-after-free in o2hb_region_dev_store+0x1751/0x1b00 fs/ocfs2/cluster/heartbeat.c:1936
Write of size 8 at addr ffff8880262b82e8 by task syz.3.20/6459
CPU: 2 UID: 0 PID: 6459 Comm: syz.3.20 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x13d/0x4b0 mm/kasan/report.c:482
kasan_report+0xdf/0x1c0 mm/kasan/report.c:595
o2hb_map_slot_data fs/ocfs2/cluster/heartbeat.c:1811 [inline]
o2hb_region_dev_store+0x1751/0x1b00 fs/ocfs2/cluster/heartbeat.c:1936
flush_write_buffer fs/configfs/file.c:207 [inline]
configfs_write_iter+0x302/0x4e0 fs/configfs/file.c:229
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x6af/0x1050 fs/read_write.c:687
ksys_write+0x12a/0x250 fs/read_write.c:739
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f79d5d9e019
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f79d6c1c028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f79d6025fa0 RCX: 00007f79d5d9e019
RDX: 0000000000000001 RSI: 00002000000005c0 RDI: 0000000000000004
RBP: 00007f79d5e3500c R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f79d6026038 R14: 00007f79d6025fa0 R15: 00007ffc42008128
</TASK>
Allocated by task 6459:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__do_kmalloc_node mm/slub.c:5414 [inline]
__kmalloc_noprof+0x32f/0x840 mm/slub.c:5439
_kmalloc_noprof include/linux/slab.h:995 [inline]
_kzalloc_noprof include/linux/slab.h:1312 [inline]
o2hb_map_slot_data fs/ocfs2/cluster/heartbeat.c:1802 [inline]
o2hb_region_dev_store+0x88b/0x1b00 fs/ocfs2/cluster/heartbeat.c:1936
flush_write_buffer fs/configfs/file.c:207 [inline]
configfs_write_iter+0x302/0x4e0 fs/configfs/file.c:229
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x6af/0x1050 fs/read_write.c:687
ksys_write+0x12a/0x250 fs/read_write.c:739
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 6458:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5f/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2748 [inline]
slab_free mm/slub.c:6499 [inline]
kfree+0x22b/0x6d0 mm/slub.c:6792
o2hb_unmap_slot_data+0x190/0x330 fs/ocfs2/cluster/heartbeat.c:1596
o2hb_region_dev_store+0x112e/0x1b00 fs/ocfs2/cluster/heartbeat.c:2027
flush_write_buffer fs/configfs/file.c:207 [inline]
configfs_write_iter+0x302/0x4e0 fs/configfs/file.c:229
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x6af/0x1050 fs/read_write.c:687
ksys_write+0x12a/0x250 fs/read_write.c:739
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff8880262b8200
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 232 bytes inside of
freed 256-byte region [ffff8880262b8200, ffff8880262b8300)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x262b8
head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88801c042b40 dead000000000100 dead000000000122
raw: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
head: 00fff00000000040 ffff88801c042b40 dead000000000100 dead000000000122
head: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
head: 00fff00000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 1, migratetype Unmovable, gfp_mask 0xd2040(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 39, tgid 39 (kdevtmpfs), ts 6186544854
set_page_owner include/linux/page_owner.h:33 [inline]
post_alloc_hook+0xfd/0x120 mm/page_alloc.c:1871
prep_new_page mm/page_alloc.c:1879 [inline]
get_page_from_freelist+0x110d/0x35d0 mm/page_alloc.c:3943
__alloc_frozen_pages_noprof+0x2eb/0x3300 mm/page_alloc.c:5436
alloc_slab_page mm/slub.c:3347 [inline]
allocate_slab mm/slub.c:3462 [inline]
new_slab+0xa9/0x6e0 mm/slub.c:3513
refill_objects+0xe3/0x410 mm/slub.c:7410
refill_sheaf mm/slub.c:2885 [inline]
__pcs_replace_empty_main+0x35e/0x650 mm/slub.c:4774
alloc_from_pcs mm/slub.c:4850 [inline]
slab_alloc_node mm/slub.c:4984 [inline]
__do_kmalloc_node mm/slub.c:5413 [inline]
__kmalloc_noprof+0x67c/0x840 mm/slub.c:5439
_kmalloc_noprof include/linux/slab.h:995 [inline]
_kmalloc_array_noprof include/linux/slab.h:1211 [inline]
security_inode_init_security+0x113/0x370 security/security.c:1347
shmem_mknod+0x2ce/0x480 mm/shmem.c:3838
vfs_mknod+0x3a5/0x7f0 fs/namei.c:5269
handle_create drivers/base/devtmpfs.c:232 [inline]
handle drivers/base/devtmpfs.c:384 [inline]
devtmpfs_work_loop+0x48d/0xae4 drivers/base/devtmpfs.c:399
devtmpfsd+0x3f/0x50 drivers/base/devtmpfs.c:441
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
page_owner free stack trace missing
Memory state around the buggy address:
ffff8880262b8180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880262b8200: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880262b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880262b8300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880262b8380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply [flat|nested] 4+ messages in thread
* Forwarded: [PATCH] ocfs2: fix use-after-free in o2hb_region_dev_store
2026-09-04 22:00 [syzbot] KASAN: slab-use-after-free Write in o2hb_region_dev_store syzbot
@ 2026-09-04 23:35 ` syzbot
2026-10-20 8:30 ` syzbot
2026-10-20 8:30 ` syzbot
2 siblings, 0 replies; 4+ messages in thread
From: syzbot @ 2026-09-04 23:35 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ocfs2: fix use-after-free in o2hb_region_dev_store
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Concurrent writes to a region's "dev" attribute can race, letting two
tasks both allocate/free reg->hr_slot_data for the same region and
causing a use-after-free. Add a per-region mutex to serialize
o2hb_region_dev_store() against itself and against
o2hb_region_release().
Reported-by: syzbot+3025e3e8fc0b928af8f5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3025e3e8fc0b928af8f5
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
fs/ocfs2/cluster/heartbeat.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index 1c3def99bb07..6f03de1b6d4a 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -273,6 +273,9 @@ struct o2hb_region {
/* last hb status, 0 for success, other value for error. */
int hr_last_hb_status;
+ /* Serializes dev_store() against itself and region_release() */
+ struct mutex hr_dev_write_mutex;
+
};
static inline struct block_device *reg_bdev(struct o2hb_region *reg)
@@ -1616,7 +1619,10 @@ static void o2hb_region_release(struct config_item *item)
o2hb_quiesce_timeout(reg);
o2net_unregister_and_flush_handler_list(®->hr_handler_list);
+
+ mutex_lock(®->hr_dev_write_mutex);
o2hb_unmap_slot_data(reg);
+ mutex_unlock(®->hr_dev_write_mutex);
if (reg->hr_bdev_file)
fput(reg->hr_bdev_file);
@@ -1879,9 +1885,6 @@ static ssize_t o2hb_region_dev_store(struct config_item *item,
ssize_t ret = -EINVAL;
int live_threshold;
- if (reg->hr_bdev_file)
- return -EINVAL;
-
/* We can't heartbeat without having had our node number
* configured yet. */
reg->hr_node_num = o2nm_this_node();
@@ -1906,12 +1909,20 @@ static ssize_t o2hb_region_dev_store(struct config_item *item,
if (!S_ISBLK(fd_file(f)->f_mapping->host->i_mode))
return -EINVAL;
+ if (mutex_lock_interruptible(®->hr_dev_write_mutex))
+ return -ERESTARTSYS;
+
+ if (reg->hr_bdev_file) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
reg->hr_bdev_file = bdev_file_open_by_dev(fd_file(f)->f_mapping->host->i_rdev,
BLK_OPEN_WRITE | BLK_OPEN_READ, NULL, NULL);
if (IS_ERR(reg->hr_bdev_file)) {
ret = PTR_ERR(reg->hr_bdev_file);
reg->hr_bdev_file = NULL;
- return ret;
+ goto out_unlock;
}
sectsize = bdev_logical_block_size(reg_bdev(reg));
@@ -2029,6 +2040,8 @@ static ssize_t o2hb_region_dev_store(struct config_item *item,
fput(reg->hr_bdev_file);
reg->hr_bdev_file = NULL;
}
+out_unlock:
+ mutex_unlock(®->hr_dev_write_mutex);
return ret;
}
@@ -2149,6 +2162,8 @@ static struct config_item *o2hb_heartbeat_group_make_item(struct config_group *g
config_item_init_type_name(®->hr_item, name, &o2hb_region_type);
+ mutex_init(®->hr_dev_write_mutex);
+
/* this is the same way to generate msg key as dlm, for local heartbeat,
* name is also the same, so make initial crc value different to avoid
* message key conflict.
--
2.34.1
^ permalink raw reply [flat|nested] 4+ messages in thread
* Forwarded: [PATCH] ocfs2: fix use-after-free in o2hb_region_dev_store
2026-09-04 22:00 [syzbot] KASAN: slab-use-after-free Write in o2hb_region_dev_store syzbot
2026-09-04 23:35 ` Forwarded: [PATCH] ocfs2: fix use-after-free " syzbot
@ 2026-10-20 8:30 ` syzbot
2026-10-20 8:30 ` syzbot
2 siblings, 0 replies; 4+ messages in thread
From: syzbot @ 2026-10-20 8:30 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ocfs2: fix use-after-free in o2hb_region_dev_store
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Two tasks can concurrently write to the same region's "dev" configfs
attribute, each through its own open fd. configfs does not serialize
separate fds against each other here.
The only guard against a second writer is an unlocked check near the
top of o2hb_region_dev_store():
if (reg->hr_bdev_file)
return -EINVAL;
This check happens well before hr_bdev_file is actually assigned;
several validation steps and an fd lookup sit in between. If a second
task runs this same check before the first task has assigned
hr_bdev_file, it also reads NULL and also proceeds.
Both tasks then call o2hb_map_slot_data(), which allocates
reg->hr_slot_data, and later, on any failure, o2hb_unmap_slot_data(),
which frees it. Since hr_slot_data is also unprotected, one task can
free it through its failure path while the other task is still
populating the array, producing the use-after-free reported by syzbot.
Race flow:
T1: dev_store() T2: dev_store()
if (reg->hr_bdev_file) // NULL if (reg->hr_bdev_file) // NULL
... ...
reg->hr_bdev_file = ...
o2hb_map_slot_data()
alloc reg->hr_slot_data
populating slots...
reg->hr_bdev_file = ...
o2hb_map_slot_data()
failure -> out:
o2hb_unmap_slot_data()
frees reg->hr_slot_data
writes to freed slot data <-- UAF
Fix this by adding a per-region mutex, taken at the top of
o2hb_region_dev_store() before any region state is modified and held
until the function returns.
Reported-by: syzbot+3025e3e8fc0b928af8f5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3025e3e8fc0b928af8f5
Assisted-by: Claude
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
v2:
- Expanded the description with the race flow
- Updated Fixes: tag
- Use tab for indentation
- Dropped locking in o2hb_region_release(); configfs already
serializes store and rmdir
- Take the lock before the hr_node_num assignment, using
guard(mutex) so every early return releases it
---
fs/ocfs2/cluster/heartbeat.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index 1c3def99bb07..e20ef0459f54 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -273,6 +273,8 @@ struct o2hb_region {
/* last hb status, 0 for success, other value for error. */
int hr_last_hb_status;
+ /* Serializes concurrent writers of the "dev" attribute */
+ struct mutex hr_dev_write_mutex;
};
static inline struct block_device *reg_bdev(struct o2hb_region *reg)
@@ -1879,6 +1881,8 @@ static ssize_t o2hb_region_dev_store(struct config_item *item,
ssize_t ret = -EINVAL;
int live_threshold;
+ guard(mutex)(®->hr_dev_write_mutex);
+
if (reg->hr_bdev_file)
return -EINVAL;
@@ -2149,6 +2153,8 @@ static struct config_item *o2hb_heartbeat_group_make_item(struct config_group *g
config_item_init_type_name(®->hr_item, name, &o2hb_region_type);
+ mutex_init(®->hr_dev_write_mutex);
+
/* this is the same way to generate msg key as dlm, for local heartbeat,
* name is also the same, so make initial crc value different to avoid
* message key conflict.
--
2.43.0
^ permalink raw reply [flat|nested] 4+ messages in thread
* Forwarded: [PATCH] ocfs2: fix use-after-free in o2hb_region_dev_store
2026-09-04 22:00 [syzbot] KASAN: slab-use-after-free Write in o2hb_region_dev_store syzbot
2026-09-04 23:35 ` Forwarded: [PATCH] ocfs2: fix use-after-free " syzbot
2026-10-20 8:30 ` syzbot
@ 2026-10-20 8:30 ` syzbot
2 siblings, 0 replies; 4+ messages in thread
From: syzbot @ 2026-10-20 8:30 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ocfs2: fix use-after-free in o2hb_region_dev_store
Author: kartikey406@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Two tasks can concurrently write to the same region's "dev" configfs
attribute, each through its own open fd. configfs does not serialize
separate fds against each other here.
The only guard against a second writer is an unlocked check near the
top of o2hb_region_dev_store():
if (reg->hr_bdev_file)
return -EINVAL;
This check happens well before hr_bdev_file is actually assigned;
several validation steps and an fd lookup sit in between. If a second
task runs this same check before the first task has assigned
hr_bdev_file, it also reads NULL and also proceeds.
Both tasks then call o2hb_map_slot_data(), which allocates
reg->hr_slot_data, and later, on any failure, o2hb_unmap_slot_data(),
which frees it. Since hr_slot_data is also unprotected, one task can
free it through its failure path while the other task is still
populating the array, producing the use-after-free reported by syzbot.
Race flow:
T1: dev_store() T2: dev_store()
if (reg->hr_bdev_file) // NULL if (reg->hr_bdev_file) // NULL
... ...
reg->hr_bdev_file = ...
o2hb_map_slot_data()
alloc reg->hr_slot_data
populating slots...
reg->hr_bdev_file = ...
o2hb_map_slot_data()
failure -> out:
o2hb_unmap_slot_data()
frees reg->hr_slot_data
writes to freed slot data <-- UAF
Fix this by adding a per-region mutex, taken at the top of
o2hb_region_dev_store() before any region state is modified and held
until the function returns.
Reported-by: syzbot+3025e3e8fc0b928af8f5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3025e3e8fc0b928af8f5
Assisted-by: Claude
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
v2:
- Expanded the description with the race flow
- Updated Fixes: tag
- Use tab for indentation
- Dropped locking in o2hb_region_release(); configfs already
serializes store and rmdir
- Take the lock before the hr_node_num assignment, using
guard(mutex) so every early return releases it
---
fs/ocfs2/cluster/heartbeat.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
index 1c3def99bb07..e20ef0459f54 100644
--- a/fs/ocfs2/cluster/heartbeat.c
+++ b/fs/ocfs2/cluster/heartbeat.c
@@ -273,6 +273,8 @@ struct o2hb_region {
/* last hb status, 0 for success, other value for error. */
int hr_last_hb_status;
+ /* Serializes concurrent writers of the "dev" attribute */
+ struct mutex hr_dev_write_mutex;
};
static inline struct block_device *reg_bdev(struct o2hb_region *reg)
@@ -1879,6 +1881,8 @@ static ssize_t o2hb_region_dev_store(struct config_item *item,
ssize_t ret = -EINVAL;
int live_threshold;
+ guard(mutex)(®->hr_dev_write_mutex);
+
if (reg->hr_bdev_file)
return -EINVAL;
@@ -2149,6 +2153,8 @@ static struct config_item *o2hb_heartbeat_group_make_item(struct config_group *g
config_item_init_type_name(®->hr_item, name, &o2hb_region_type);
+ mutex_init(®->hr_dev_write_mutex);
+
/* this is the same way to generate msg key as dlm, for local heartbeat,
* name is also the same, so make initial crc value different to avoid
* message key conflict.
--
2.43.0
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-10-20 8:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-04 22:00 [syzbot] KASAN: slab-use-after-free Write in o2hb_region_dev_store syzbot
2026-09-04 23:35 ` Forwarded: [PATCH] ocfs2: fix use-after-free " syzbot
2026-10-20 8:30 ` syzbot
2026-10-20 8:30 ` syzbot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®