[syzbot] [ext4?] KASAN: use-after-free Read in xattr_find_entry (2)

7 views
Skip to first unread message

syzbot

unread,
Feb 22, 2026, 7:12:33 PMFeb 22
to adilger...@dilger.ca, linux...@vger.kernel.org, linux-...@vger.kernel.org, syzkall...@googlegroups.com, ty...@mit.edu
Hello,

syzbot found the following issue on:

HEAD commit: 2961f841b025 Merge tag 'turbostat-2026.02.14' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=156cb15a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=665cbf0979cda6c5
dashboard link: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17a43b3a580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=157f895a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/54d6a30cbc5f/disk-2961f841.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/40003e4ec76c/vmlinux-2961f841.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2db393aba9ff/bzImage-2961f841.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/07bdbcf04dc1/mount_0.gz
fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=12b95c02580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+fb32af...@syzkaller.appspotmail.com

loop0: detected capacity change from 1024 to 64
EXT4-fs error (device loop0): ext4_find_dest_de:2050: inode #12: block 7: comm syz.0.17: bad entry in directory: directory entry overrun - offset=0, inode=268435456, rec_len=1280, size=56 fake=0
==================================================================
BUG: KASAN: use-after-free in xattr_find_entry+0x1a5/0x280 fs/ext4/xattr.c:334
Read of size 4 at addr ffff88806ee29004 by task syz.0.17/5997

CPU: 1 UID: 49663 PID: 5997 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xba/0x230 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
xattr_find_entry+0x1a5/0x280 fs/ext4/xattr.c:334
ext4_xattr_ibody_get+0x232/0x4c0 fs/ext4/xattr.c:655
ext4_xattr_get+0x123/0x6a0 fs/ext4/xattr.c:709
ext4_get_acl+0x84/0x930 fs/ext4/acl.c:165
__get_acl+0x27e/0x410 fs/posix_acl.c:159
check_acl+0x3a/0x150 fs/namei.c:385
acl_permission_check fs/namei.c:471 [inline]
generic_permission+0x497/0x690 fs/namei.c:524
do_inode_permission fs/namei.c:585 [inline]
inode_permission+0x243/0x5f0 fs/namei.c:648
lookup_inode_permission_may_exec fs/namei.c:-1 [inline]
may_lookup fs/namei.c:1973 [inline]
link_path_walk+0x1149/0x18d0 fs/namei.c:2595
path_lookupat+0xe4/0x8c0 fs/namei.c:2803
filename_lookup+0x256/0x5d0 fs/namei.c:2833
user_path_at+0x40/0x160 fs/namei.c:3612
do_mount fs/namespace.c:4156 [inline]
__do_sys_mount fs/namespace.c:4348 [inline]
__se_sys_mount+0x2dc/0x420 fs/namespace.c:4325
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f72cdd9c629
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:00007fff6aba2c28 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f72ce015fa0 RCX: 00007f72cdd9c629
RDX: 0000000000000000 RSI: 0000200000000040 RDI: 0000000000000000
RBP: 00007f72cde32b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000002094080 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f72ce015fac R14: 00007f72ce015fa0 R15: 00007f72ce015fa0
</TASK>

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x7f3283789 pfn:0x6ee29
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 ffffea0001bb8a88 ffffea0001bb8908 0000000000000000
raw: 00000007f3283789 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO|__GFP_COMP), pid 5981, tgid 5981 (sed), ts 108386366383, free_ts 108399318838
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1888
prep_new_page mm/page_alloc.c:1896 [inline]
get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3961
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5249
alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2485
folio_alloc_mpol_noprof mm/mempolicy.c:2504 [inline]
vma_alloc_folio_noprof+0xea/0x210 mm/mempolicy.c:2539
folio_prealloc mm/memory.c:-1 [inline]
alloc_anon_folio mm/memory.c:5200 [inline]
do_anonymous_page mm/memory.c:5257 [inline]
do_pte_missing+0x1656/0x3750 mm/memory.c:4467
handle_pte_fault mm/memory.c:6308 [inline]
__handle_mm_fault mm/memory.c:6446 [inline]
handle_mm_fault+0x1bec/0x3310 mm/memory.c:6615
do_user_addr_fault+0xa73/0x1340 arch/x86/mm/fault.c:1334
handle_page_fault arch/x86/mm/fault.c:1474 [inline]
exc_page_fault+0x6a/0xc0 arch/x86/mm/fault.c:1527
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
page last free pid 5981 tgid 5981 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1432 [inline]
free_unref_folios+0xd38/0x14c0 mm/page_alloc.c:3039
folios_put_refs+0x789/0x8d0 mm/swap.c:1002
free_pages_and_swap_cache+0x2e7/0x5b0 mm/swap_state.c:423
__tlb_batch_free_encoded_pages mm/mmu_gather.c:138 [inline]
tlb_batch_pages_flush mm/mmu_gather.c:151 [inline]
tlb_flush_mmu_free mm/mmu_gather.c:398 [inline]
tlb_flush_mmu+0x6d3/0xa30 mm/mmu_gather.c:405
tlb_finish_mmu+0xf9/0x230 mm/mmu_gather.c:530
exit_mmap+0x453/0xdb0 mm/mmap.c:1290
__mmput+0x118/0x430 kernel/fork.c:1174
exit_mm+0x168/0x220 kernel/exit.c:581
do_exit+0x62e/0x2320 kernel/exit.c:959
do_group_exit+0x21b/0x2d0 kernel/exit.c:1112
__do_sys_exit_group kernel/exit.c:1123 [inline]
__se_sys_exit_group kernel/exit.c:1121 [inline]
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121
x64_sys_call+0x221a/0x2240 arch/x86/include/generated/asm/syscalls_64.h:232
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
ffff88806ee28f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88806ee28f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88806ee29000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88806ee29080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88806ee29100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


---
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 syzk...@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

syzbot

unread,
Feb 24, 2026, 3:36:21 AMFeb 24
to linux-...@vger.kernel.org, syzkall...@googlegroups.com
For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] ext4: add bounds check in xattr_find_entry() to prevent use-after-free
Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


xattr_find_entry() receives an 'end' pointer to mark the boundary of
the valid xattr region, but never uses it to validate entries during
iteration. The IS_LAST_ENTRY() check dereferences the entry pointer
(reading 4 bytes) without first verifying that the entry is within
bounds. On a corrupted filesystem, this allows the loop to walk past
the valid buffer into freed memory, triggering a use-after-free.

This is observed when mounting a crafted ext4 image where inline xattr
entries in the inode body are corrupted. During path lookup, the ACL
permission check calls ext4_get_acl() -> ext4_xattr_ibody_get() ->
xattr_find_entry(), which iterates over the corrupted inline xattr
entries and reads from a freed page.

Fix this by adding a bounds check against 'end' before each entry
is accessed in the iteration loop, and validating that the next entry
also falls within bounds. Return -EFSCORRUPTED if the xattr entries
overrun the valid region.

Reported-by: syzbot+fb32af...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/ext4/xattr.c | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..5080ec44228a 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -652,6 +652,13 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,
header = IHDR(inode, raw_inode);
end = ITAIL(inode, raw_inode);
entry = IFIRST(header);
+
+ if ((void *)entry + sizeof(__u32) > end) {
+ EXT4_ERROR_INODE(inode, "inline xattr region overflow");
+ error = -EFSCORRUPTED;
+ goto cleanup;
+ }
+
error = xattr_find_entry(inode, &entry, end, name_index, name, 0);
if (error)
goto cleanup;
--
2.34.1

syzbot

unread,
Feb 24, 2026, 3:52:25 AMFeb 24
to linux-...@vger.kernel.org, syzkall...@googlegroups.com
For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] ext4: add bounds check in xattr_find_entry() to prevent use-after-free
Author: karti...@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master



xattr_find_entry() receives an 'end' pointer to mark the boundary of
the valid xattr region but never uses it to validate entries during
iteration. The IS_LAST_ENTRY() macro dereferences the entry pointer
by casting it to __u32 and reading 4 bytes, without first verifying
that the entry falls within bounds.

On a corrupted filesystem, inline xattr entries in the inode body can
have a bogus e_name_len field. EXT4_XATTR_NEXT() uses e_name_len to
compute the next entry offset, which can jump past the valid xattr
region into freed memory. The subsequent IS_LAST_ENTRY() call on this
out-of-bounds pointer triggers a use-after-free read.

Fix this by:
1. Checking that the entry pointer is within bounds before each
IS_LAST_ENTRY() dereference in the loop condition.
2. Validating that the next entry computed via EXT4_XATTR_NEXT()
also falls within bounds before advancing the loop.

Return -EFSCORRUPTED if entries overrun the valid xattr region.
fs/ext4/xattr.c | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..f38eef93e3f8 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -333,6 +333,12 @@ xattr_find_entry(struct inode *inode, struct ext4_xattr_entry **pentry,
name_len = strlen(name);
for (entry = *pentry; !IS_LAST_ENTRY(entry); entry = next) {
next = EXT4_XATTR_NEXT(entry);
+ if ((void *)next + sizeof(__u32) > end) {
+ EXT4_ERROR_INODE(inode, "corrupted xattr entry: e_name_len=%u",
+ entry->e_name_len);
+ return -EFSCORRUPTED;
+ }
+
if ((void *) next >= end) {
EXT4_ERROR_INODE(inode, "corrupted xattr entries");
return -EFSCORRUPTED;
@@ -652,6 +658,13 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,

syzbot

unread,
Feb 24, 2026, 4:41:03 AMFeb 24
to karti...@gmail.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+fb32af...@syzkaller.appspotmail.com
Tested-by: syzbot+fb32af...@syzkaller.appspotmail.com

Tested on:

commit: 7dff99b3 Remove WARN_ALL_UNSEEDED_RANDOM kernel config..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1699155a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=93740e6c6567fcec
dashboard link: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=15fe355a580000

Note: testing is done by a robot and is best-effort only.

syzbot

unread,
Feb 24, 2026, 5:05:05 AMFeb 24
to karti...@gmail.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+fb32af...@syzkaller.appspotmail.com
Tested-by: syzbot+fb32af...@syzkaller.appspotmail.com

Tested on:

commit: 7dff99b3 Remove WARN_ALL_UNSEEDED_RANDOM kernel config..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14f1355a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=93740e6c6567fcec
dashboard link: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=1777b722580000

syzbot

unread,
Mar 26, 2026, 10:50:54 AMĀ (4 days ago)Ā Mar 26
to linux-...@vger.kernel.org, syzkall...@googlegroups.com
For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] ext4: fix bounds check in check_xattrs() to account for IS_LAST_ENTRY() read
The bounds check for the next xattr entry in check_xattrs() uses
(void *)next >= end, which allows next to point within sizeof(u32)
bytes of end. On the next iteration, IS_LAST_ENTRY() reads 4 bytes
from next via *(__u32 *)(entry), which can overrun the valid xattr
region and access freed memory.

This is triggered when mounting a corrupted ext4 filesystem where the
inode's i_extra_isize leaves insufficient space for inline xattr
entries. The ACL permission check calls ext4_get_acl() ->
ext4_xattr_ibody_get() -> xattr_find_entry(), which reads past the
inode buffer.

Fix this by changing the check to (void *)next + sizeof(u32) > end,
ensuring there is always enough space for the IS_LAST_ENTRY() read
on the subsequent iteration.
Link: https://lore.kernel.org/all/20260224231429.31...@gmail.com/T/ [v1]
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>

---
v2: Move the fix to check_xattrs() as suggested by Ted Ts'o, instead
of adding a separate check in ext4_xattr_ibody_get().
---
fs/ext4/xattr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..c6205b405efe 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -226,7 +226,7 @@ check_xattrs(struct inode *inode, struct buffer_head *bh,
/* Find the end of the names list */
while (!IS_LAST_ENTRY(e)) {
struct ext4_xattr_entry *next = EXT4_XATTR_NEXT(e);
- if ((void *)next >= end) {
+ if ((void *)next + sizeof(u32) > end) {
err_str = "e_name out of bounds";
goto errout;
}
--
2.43.0

syzbot

unread,
Mar 27, 2026, 9:28:04 AMĀ (3 days ago)Ā Mar 27
to linux-...@vger.kernel.org, syzkall...@googlegroups.com
For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] ext4: add debug printk to trace xattr validation path
Add temporary printk statements to trace the inline xattr validation
code path for debugging syzbot use-after-free in xattr_find_entry().

This helps determine whether __xattr_check_inode() is being called
before ext4_xattr_ibody_get() accesses inline xattr entries, and
what the IFIRST/ITAIL gap values are at each stage.

Not for upstream submission - debug only.
Signed-off-by: Deepanshu Kartikey <karti...@gmail.com>
---
fs/ext4/inode.c | 4 ++++
fs/ext4/xattr.c | 8 ++++++++
2 files changed, 12 insertions(+)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 396dc3a5d16b..af3a6992bf20 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5331,11 +5331,15 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,

if (EXT4_INODE_SIZE(inode->i_sb) > EXT4_GOOD_OLD_INODE_SIZE) {
if (ei->i_extra_isize == 0) {
+ printk("DEBUG: inode %lu: i_extra_isize == 0, skipping xattr check\n",
+ inode->i_ino);
/* The extra space is currently unused. Use it. */
BUILD_BUG_ON(sizeof(struct ext4_inode) & 3);
ei->i_extra_isize = sizeof(struct ext4_inode) -
EXT4_GOOD_OLD_INODE_SIZE;
} else {
+ printk("DEBUG: inode %lu: calling ext4_iget_extra_inode\n",
+ inode->i_ino);
ret = ext4_iget_extra_inode(inode, raw_inode, ei);
if (ret)
goto bad_inode;
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..abc27521a3a8 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -316,6 +316,9 @@ int
__xattr_check_inode(struct inode *inode, struct ext4_xattr_ibody_header *header,
void *end, const char *function, unsigned int line)
{
+ printk("DEBUG: inode %lu: __xattr_check_inode called, IFIRST=%px end=%px gap=%ld\n",
+ inode->i_ino, IFIRST(header), end,
+ (long)(end - (void *)IFIRST(header)));
return check_xattrs(inode, NULL, IFIRST(header), end, IFIRST(header),
function, line);
}
@@ -645,6 +648,8 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,

if (!ext4_test_inode_state(inode, EXT4_STATE_XATTR))
return -ENODATA;
+ printk("DEBUG: inode %lu: ext4_xattr_ibody_get called, EXT4_STATE_XATTR is set\n",
+ inode->i_ino);
error = ext4_get_inode_loc(inode, &iloc);
if (error)
return error;
@@ -652,6 +657,9 @@ ext4_xattr_ibody_get(struct inode *inode, int name_index, const char *name,
header = IHDR(inode, raw_inode);
end = ITAIL(inode, raw_inode);
entry = IFIRST(header);
+ printk("DEBUG: inode %lu: ibody_get IFIRST=%px end=%px gap=%ld\n",
+ inode->i_ino, entry, end,
+ (long)(end - (void *)entry));
error = xattr_find_entry(inode, &entry, end, name_index, name, 0);
if (error)
goto cleanup;
--
2.43.0

syzbot

unread,
Mar 29, 2026, 9:43:18 PMĀ (22 hours ago)Ā Mar 29
to linux-...@vger.kernel.org, syzkall...@googlegroups.com
For archival purposes, forwarding an incoming command email to
linux-...@vger.kernel.org, syzkall...@googlegroups.com.

***

Subject: [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device
LOOP_SET_STATUS{64} allows changing lo_offset and lo_sizelimit while
a filesystem is mounted on the loop device. This effectively mutates
the data visible to the mounted filesystem, which is equivalent to
writing directly to the block device.

When bdev_allow_write_mounted is false, direct writes to a mounted
block device are blocked via bdev_writes_blocked(). However,
LOOP_SET_STATUS{64} bypasses this protection because it modifies
the loop configuration through an ioctl rather than opening the
block device for writing.

Fix this by checking bdev_writes_blocked() before allowing changes
to lo_offset or lo_sizelimit. If the loop device has writes blocked
(indicating a filesystem is mounted with write protection), return
-EBUSY. Other loop status fields that do not affect the visible
data can still be changed while mounted.

Export bdev_writes_blocked() so it can be used from the loop driver.

Suggested-by: Theodore Ts'o <ty...@mit.edu>
block/bdev.c | 4 +++-
drivers/block/loop.c | 12 ++++++++++++
include/linux/blkdev.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/block/bdev.c b/block/bdev.c
index ed022f8c48c7..96520fac7b2f 100644
--- a/block/bdev.c
+++ b/block/bdev.c
@@ -860,10 +860,12 @@ void blkdev_put_no_open(struct block_device *bdev)
put_device(&bdev->bd_device);
}

-static bool bdev_writes_blocked(struct block_device *bdev)
+bool bdev_writes_blocked(struct block_device *bdev)
{
return bdev->bd_writers < 0;
}
+EXPORT_SYMBOL_GPL(bdev_writes_blocked);
+

static void bdev_block_writes(struct block_device *bdev)
{
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 0000913f7efc..3f3a29abad1f 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1239,6 +1239,18 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
goto out_unlock;
}

+ /*
+ * Changing lo_offset or lo_sizelimit on a mounted device is
+ * equivalent to modifying the block device contents, block
+ * this if writes are blocked on the device.
+ */
+ if ((lo->lo_offset != info->lo_offset ||
+ lo->lo_sizelimit != info->lo_sizelimit) &&
+ bdev_writes_blocked(lo->lo_device)) {
+ err = -EBUSY;
+ goto out_unlock;
+ }
+
if (lo->lo_offset != info->lo_offset ||
lo->lo_sizelimit != info->lo_sizelimit) {
size_changed = true;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d463b9b5a0a5..6b908e9dd035 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -820,6 +820,7 @@ static inline bool bdev_read_only(struct block_device *bdev)
return bdev_test_flag(bdev, BD_READ_ONLY) || get_disk_ro(bdev->bd_disk);
}

+bool bdev_writes_blocked(struct block_device *bdev);
bool set_capacity_and_notify(struct gendisk *disk, sector_t size);
void disk_force_media_change(struct gendisk *disk);
void bdev_mark_dead(struct block_device *bdev, bool surprise);
--
2.43.0

Reply all
Reply to author
Forward
0 new messages