Vulnerabilities

In limited scenarios, sensitive data might be written to the log file if an admin uses Microsoft Teams Admin Center (TAC) to make device configuration changes. The affected log file is visible only to users with admin credentials. This is limited to Microsoft TAC and does not affect configuration changes made using the provisioning server or the device WebUI.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix admin request_queue lifetime<br /> <br /> The namespaces can access the controller&amp;#39;s admin request_queue, and<br /> stale references on the namespaces may exist after tearing down the<br /> controller. Ensure the admin request_queue is active by moving the<br /> controller&amp;#39;s &amp;#39;put&amp;#39; to after all controller references have been released<br /> to ensure no one is can access the request_queue. This fixes a reported<br /> use-after-free bug:<br /> <br /> BUG: KASAN: slab-use-after-free in blk_queue_enter+0x41c/0x4a0<br /> Read of size 8 at addr ffff88c0a53819f8 by task nvme/3287<br /> CPU: 67 UID: 0 PID: 3287 Comm: nvme Tainted: G E 6.13.2-ga1582f1a031e #15<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: Jabil /EGS 2S MB1, BIOS 1.00 06/18/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4f/0x60<br /> print_report+0xc4/0x620<br /> ? _raw_spin_lock_irqsave+0x70/0xb0<br /> ? _raw_read_unlock_irqrestore+0x30/0x30<br /> ? blk_queue_enter+0x41c/0x4a0<br /> kasan_report+0xab/0xe0<br /> ? blk_queue_enter+0x41c/0x4a0<br /> blk_queue_enter+0x41c/0x4a0<br /> ? __irq_work_queue_local+0x75/0x1d0<br /> ? blk_queue_start_drain+0x70/0x70<br /> ? irq_work_queue+0x18/0x20<br /> ? vprintk_emit.part.0+0x1cc/0x350<br /> ? wake_up_klogd_work_func+0x60/0x60<br /> blk_mq_alloc_request+0x2b7/0x6b0<br /> ? __blk_mq_alloc_requests+0x1060/0x1060<br /> ? __switch_to+0x5b7/0x1060<br /> nvme_submit_user_cmd+0xa9/0x330<br /> nvme_user_cmd.isra.0+0x240/0x3f0<br /> ? force_sigsegv+0xe0/0xe0<br /> ? nvme_user_cmd64+0x400/0x400<br /> ? vfs_fileattr_set+0x9b0/0x9b0<br /> ? cgroup_update_frozen_flag+0x24/0x1c0<br /> ? cgroup_leave_frozen+0x204/0x330<br /> ? nvme_ioctl+0x7c/0x2c0<br /> blkdev_ioctl+0x1a8/0x4d0<br /> ? blkdev_common_ioctl+0x1930/0x1930<br /> ? fdget+0x54/0x380<br /> __x64_sys_ioctl+0x129/0x190<br /> do_syscall_64+0x5b/0x160<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f765f703b0b<br /> Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d dd 52 0f 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffe2cefe808 EFLAGS: 00000202 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffe2cefe860 RCX: 00007f765f703b0b<br /> RDX: 00007ffe2cefe860 RSI: 00000000c0484e41 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000<br /> R10: 00007f765f611d50 R11: 0000000000000202 R12: 0000000000000003<br /> R13: 00000000c0484e41 R14: 0000000000000001 R15: 00007ffe2cefea60<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bfs: Reconstruct file type when loading from disk<br /> <br /> syzbot is reporting that S_IFMT bits of inode-&gt;i_mode can become bogus when<br /> the S_IFMT bits of the 32bits "mode" field loaded from disk are corrupted<br /> or when the 32bits "attributes" field loaded from disk are corrupted.<br /> <br /> A documentation says that BFS uses only lower 9 bits of the "mode" field.<br /> But I can&amp;#39;t find an explicit explanation that the unused upper 23 bits<br /> (especially, the S_IFMT bits) are initialized with 0.<br /> <br /> Therefore, ignore the S_IFMT bits of the "mode" field loaded from disk.<br /> Also, verify that the value of the "attributes" field loaded from disk is<br /> either BFS_VREG or BFS_VDIR (because BFS supports only regular files and<br /> the root directory).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list<br /> <br /> "struct sdca_control" declares "values" field as integer array.<br /> But the memory allocated to it is of char array. This causes<br /> crash for sdca_parse_function API. This patch addresses the<br /> issue by allocating correct data size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: check device&amp;#39;s attached status in compat ioctls<br /> <br /> Syzbot identified an issue [1] that crashes kernel, seemingly due to<br /> unexistent callback dev-&gt;get_valid_routes(). By all means, this should<br /> not occur as said callback must always be set to<br /> get_zero_valid_routes() in __comedi_device_postconfig().<br /> <br /> As the crash seems to appear exclusively in i386 kernels, at least,<br /> judging from [1] reports, the blame lies with compat versions<br /> of standard IOCTL handlers. Several of them are modified and<br /> do not use comedi_unlocked_ioctl(). While functionality of these<br /> ioctls essentially copy their original versions, they do not<br /> have required sanity check for device&amp;#39;s attached status. This,<br /> in turn, leads to a possibility of calling select IOCTLs on a<br /> device that has not been properly setup, even via COMEDI_DEVCONFIG.<br /> <br /> Doing so on unconfigured devices means that several crucial steps<br /> are missed, for instance, specifying dev-&gt;get_valid_routes()<br /> callback.<br /> <br /> Fix this somewhat crudely by ensuring device&amp;#39;s attached status before<br /> performing any ioctls, improving logic consistency between modern<br /> and compat functions.<br /> <br /> [1] Syzbot report:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline]<br /> parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401<br /> do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594<br /> compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline]<br /> comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273<br /> __do_compat_sys_ioctl fs/ioctl.c:695 [inline]<br /> __se_compat_sys_ioctl fs/ioctl.c:638 [inline]<br /> __ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638<br /> do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: multiq3: sanitize config options in multiq3_attach()<br /> <br /> Syzbot identified an issue [1] in multiq3_attach() that induces a<br /> task timeout due to open() or COMEDI_DEVCONFIG ioctl operations,<br /> specifically, in the case of multiq3 driver.<br /> <br /> This problem arose when syzkaller managed to craft weird configuration<br /> options used to specify the number of channels in encoder subdevice.<br /> If a particularly great number is passed to s-&gt;n_chan in<br /> multiq3_attach() via it-&gt;options[2], then multiple calls to<br /> multiq3_encoder_reset() at the end of driver-specific attach() method<br /> will be running for minutes, thus blocking tasks and affected devices<br /> as well.<br /> <br /> While this issue is most likely not too dangerous for real-life<br /> devices, it still makes sense to sanitize configuration inputs. Enable<br /> a sensible limit on the number of encoder chips (4 chips max, each<br /> with 2 channels) to stop this behaviour from manifesting.<br /> <br /> [1] Syzbot crash:<br /> INFO: task syz.2.19:6067 blocked for more than 143 seconds.<br /> ...<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5254 [inline]<br /> __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862<br /> __schedule_loop kernel/sched/core.c:6944 [inline]<br /> schedule+0x165/0x360 kernel/sched/core.c:6959<br /> schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016<br /> __mutex_lock_common kernel/locking/mutex.c:676 [inline]<br /> __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760<br /> comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868<br /> chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414<br /> do_dentry_open+0x953/0x13f0 fs/open.c:965<br /> vfs_open+0x3b/0x340 fs/open.c:1097<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Don&amp;#39;t skip unrelated instruction if INT3/INTO is replaced<br /> <br /> When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn<br /> instruction, discard the exception and retry the instruction if the code<br /> stream is changed (e.g. by a different vCPU) between when the CPU<br /> executes the instruction and when KVM decodes the instruction to get the<br /> next RIP.<br /> <br /> As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject<br /> INT3/INTO instead of retrying the instruction"), failure to verify that<br /> the correct INTn instruction was decoded can effectively clobber guest<br /> state due to decoding the wrong instruction and thus specifying the<br /> wrong next RIP.<br /> <br /> The bug most often manifests as "Oops: int3" panics on static branch<br /> checks in Linux guests. Enabling or disabling a static branch in Linux<br /> uses the kernel&amp;#39;s "text poke" code patching mechanism. To modify code<br /> while other CPUs may be executing that code, Linux (temporarily)<br /> replaces the first byte of the original instruction with an int3 (opcode<br /> 0xcc), then patches in the new code stream except for the first byte,<br /> and finally replaces the int3 with the first byte of the new code<br /> stream. If a CPU hits the int3, i.e. executes the code while it&amp;#39;s being<br /> modified, then the guest kernel must look up the RIP to determine how to<br /> handle the #BP, e.g. by emulating the new instruction. If the RIP is<br /> incorrect, then this lookup fails and the guest kernel panics.<br /> <br /> The bug reproduces almost instantly by hacking the guest kernel to<br /> repeatedly check a static branch[1] while running a drgn script[2] on<br /> the host to constantly swap out the memory containing the guest&amp;#39;s TSS.<br /> <br /> [1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a<br /> [2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: fix race condition on death_list<br /> <br /> Rust Binder contains the following unsafe operation:<br /> <br /> // SAFETY: A `NodeDeath` is never inserted into the death list<br /> // of any node other than its owner, so it is either in this<br /> // death list or in no death list.<br /> unsafe { node_inner.death_list.remove(self) };<br /> <br /> This operation is unsafe because when touching the prev/next pointers of<br /> a list element, we have to ensure that no other thread is also touching<br /> them in parallel. If the node is present in the list that `remove` is<br /> called on, then that is fine because we have exclusive access to that<br /> list. If the node is not in any list, then it&amp;#39;s also ok. But if it&amp;#39;s<br /> present in a different list that may be accessed in parallel, then that<br /> may be a data race on the prev/next pointers.<br /> <br /> And unfortunately that is exactly what is happening here. In<br /> Node::release, we:<br /> <br /> 1. Take the lock.<br /> 2. Move all items to a local list on the stack.<br /> 3. Drop the lock.<br /> 4. Iterate the local list on the stack.<br /> <br /> Combined with threads using the unsafe remove method on the original<br /> list, this leads to memory corruption of the prev/next pointers. This<br /> leads to crashes like this one:<br /> <br /> Unable to handle kernel paging request at virtual address 000bb9841bcac70e<br /> Mem abort info:<br /> ESR = 0x0000000096000044<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000<br /> CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [000bb9841bcac70e] address between user and kernel address ranges<br /> Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP<br /> google-cdd 538c004.gcdd: context saved(CPU:1)<br /> item - log_kevents is disabled<br /> Modules linked in: ... rust_binder<br /> CPU: 1 UID: 0 PID: 2092 Comm: kworker/1:178 Tainted: G S W OE 6.12.52-android16-5-g98debd5df505-4k #1 f94a6367396c5488d635708e43ee0c888d230b0b<br /> Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: MUSTANG PVT 1.0 based on LGA (DT)<br /> Workqueue: events _RNvXs6_NtCsdfZWD8DztAw_6kernel9workqueueINtNtNtB7_4sync3arc3ArcNtNtCs8QPsHWIn21X_16rust_binder_main7process7ProcessEINtB5_15WorkItemPointerKy0_E3runB13_ [rust_binder]<br /> pstate: 23400005 (nzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : _RNvXs3_NtCs8QPsHWIn21X_16rust_binder_main7processNtB5_7ProcessNtNtCsdfZWD8DztAw_6kernel9workqueue8WorkItem3run+0x450/0x11f8 [rust_binder]<br /> lr : _RNvXs3_NtCs8QPsHWIn21X_16rust_binder_main7processNtB5_7ProcessNtNtCsdfZWD8DztAw_6kernel9workqueue8WorkItem3run+0x464/0x11f8 [rust_binder]<br /> sp : ffffffc09b433ac0<br /> x29: ffffffc09b433d30 x28: ffffff8821690000 x27: ffffffd40cbaa448<br /> x26: ffffff8821690000 x25: 00000000ffffffff x24: ffffff88d0376578<br /> x23: 0000000000000001 x22: ffffffc09b433c78 x21: ffffff88e8f9bf40<br /> x20: ffffff88e8f9bf40 x19: ffffff882692b000 x18: ffffffd40f10bf00<br /> x17: 00000000c006287d x16: 00000000c006287d x15: 00000000000003b0<br /> x14: 0000000000000100 x13: 000000201cb79ae0 x12: fffffffffffffff0<br /> x11: 0000000000000000 x10: 0000000000000001 x9 : 0000000000000000<br /> x8 : b80bb9841bcac706 x7 : 0000000000000001 x6 : fffffffebee63f30<br /> x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000<br /> x2 : 0000000000004c31 x1 : ffffff88216900c0 x0 : ffffff88e8f9bf00<br /> Call trace:<br /> _RNvXs3_NtCs8QPsHWIn21X_16rust_binder_main7processNtB5_7ProcessNtNtCsdfZWD8DztAw_6kernel9workqueue8WorkItem3run+0x450/0x11f8 [rust_binder bbc172b53665bbc815363b22e97e3f7e3fe971fc]<br /> process_scheduled_works+0x1c4/0x45c<br /> worker_thread+0x32c/0x3e8<br /> kthread+0x11c/0x1c8<br /> ret_from_fork+0x10/0x20<br /> Code: 94218d85 b4000155 a94026a8 d10102a0 (f9000509)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Thus, modify Node::release to pop items directly off the original list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()<br /> <br /> Fix a race between inline data destruction and block mapping.<br /> <br /> The function ext4_destroy_inline_data_nolock() changes the inode data<br /> layout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.<br /> At the same time, another thread may execute ext4_map_blocks(), which<br /> tests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()<br /> or ext4_ind_map_blocks().<br /> <br /> Without i_data_sem protection, ext4_ind_map_blocks() may receive inode<br /> with EXT4_INODE_EXTENTS flag and triggering assert.<br /> <br /> kernel BUG at fs/ext4/indirect.c:546!<br /> EXT4-fs (loop2): unmounting filesystem.<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546<br /> <br /> Call Trace:<br /> <br /> ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681<br /> _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822<br /> ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124<br /> ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255<br /> ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000<br /> generic_perform_write+0x259/0x5d0 mm/filemap.c:3846<br /> ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285<br /> ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679<br /> call_write_iter include/linux/fs.h:2271 [inline]<br /> do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735<br /> do_iter_write+0x186/0x710 fs/read_write.c:861<br /> vfs_iter_write+0x70/0xa0 fs/read_write.c:902<br /> iter_file_splice_write+0x73b/0xc90 fs/splice.c:685<br /> do_splice_from fs/splice.c:763 [inline]<br /> direct_splice_actor+0x10f/0x170 fs/splice.c:950<br /> splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896<br /> do_splice_direct+0x1a9/0x280 fs/splice.c:1002<br /> do_sendfile+0xb13/0x12c0 fs/read_write.c:1255<br /> __do_sys_sendfile64 fs/read_write.c:1323 [inline]<br /> __se_sys_sendfile64 fs/read_write.c:1309 [inline]<br /> __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: zstd - fix double-free in per-CPU stream cleanup<br /> <br /> The crypto/zstd module has a double-free bug that occurs when multiple<br /> tfms are allocated and freed.<br /> <br /> The issue happens because zstd_streams (per-CPU contexts) are freed in<br /> zstd_exit() during every tfm destruction, rather than being managed at<br /> the module level. When multiple tfms exist, each tfm exit attempts to<br /> free the same shared per-CPU streams, resulting in a double-free.<br /> <br /> This leads to a stack trace similar to:<br /> <br /> BUG: Bad page state in process kworker/u16:1 pfn:106fd93<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x106fd93<br /> flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)<br /> page_type: 0xffffffff()<br /> raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: nonzero entire_mapcount<br /> Modules linked in: ...<br /> CPU: 3 UID: 0 PID: 2506 Comm: kworker/u16:1 Kdump: loaded Tainted: G B<br /> Hardware name: ...<br /> Workqueue: btrfs-delalloc btrfs_work_helper<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5d/0x80<br /> bad_page+0x71/0xd0<br /> free_unref_page_prepare+0x24e/0x490<br /> free_unref_page+0x60/0x170<br /> crypto_acomp_free_streams+0x5d/0xc0<br /> crypto_acomp_exit_tfm+0x23/0x50<br /> crypto_destroy_tfm+0x60/0xc0<br /> ...<br /> <br /> Change the lifecycle management of zstd_streams to free the streams only<br /> once during module cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: ipc: fix use-after-free in ipc_msg_send_request<br /> <br /> ipc_msg_send_request() waits for a generic netlink reply using an<br /> ipc_msg_table_entry on the stack. The generic netlink handler<br /> (handle_generic_event()/handle_response()) fills entry-&gt;response under<br /> ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free<br /> entry-&gt;response without holding the same lock.<br /> <br /> Under high concurrency this allows a race where handle_response() is<br /> copying data into entry-&gt;response while ipc_msg_send_request() has just<br /> freed it, leading to a slab-use-after-free reported by KASAN in<br /> handle_generic_event():<br /> <br /> BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd]<br /> Write of size 12 at addr ffff888198ee6e20 by task pool/109349<br /> ...<br /> Freed by task:<br /> kvfree<br /> ipc_msg_send_request [ksmbd]<br /> ksmbd_rpc_open -&gt; ksmbd_session_rpc_open [ksmbd]<br /> <br /> Fix by:<br /> - Taking ipc_msg_table_lock in ipc_msg_send_request() while validating<br /> entry-&gt;response, freeing it when invalid, and removing the entry from<br /> ipc_msg_table.<br /> - Returning the final entry-&gt;response pointer to the caller only after<br /> the hash entry is removed under the lock.<br /> - Returning NULL in the error path, preserving the original API<br /> semantics.<br /> <br /> This makes all accesses to entry-&gt;response consistent with<br /> handle_response(), which already updates and fills the response buffer<br /> under ipc_msg_table_lock, and closes the race that allowed the UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: refresh inline data size before write operations<br /> <br /> The cached ei-&gt;i_inline_size can become stale between the initial size<br /> check and when ext4_update_inline_data()/ext4_create_inline_data() use<br /> it. Although ext4_get_max_inline_size() reads the correct value at the<br /> time of the check, concurrent xattr operations can modify i_inline_size<br /> before ext4_write_lock_xattr() is acquired.<br /> <br /> This causes ext4_update_inline_data() and ext4_create_inline_data() to<br /> work with stale capacity values, leading to a BUG_ON() crash in<br /> ext4_write_inline_data():<br /> <br /> kernel BUG at fs/ext4/inline.c:1331!<br /> BUG_ON(pos + len &gt; EXT4_I(inode)-&gt;i_inline_size);<br /> <br /> The race window:<br /> 1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)<br /> 2. Size check passes for 50-byte write<br /> 3. [Another thread adds xattr, i_inline_size changes to 40]<br /> 4. ext4_write_lock_xattr() acquires lock<br /> 5. ext4_update_inline_data() uses stale i_inline_size = 60<br /> 6. Attempts to write 50 bytes but only 40 bytes actually available<br /> 7. BUG_ON() triggers<br /> <br /> Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock()<br /> immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()<br /> and ext4_create_inline_data() work with current values that are protected<br /> from concurrent modifications.<br /> <br /> This is similar to commit a54c4613dac1 ("ext4: fix race writing to an<br /> inline_data file while its xattrs are changing") which fixed i_inline_off<br /> staleness. This patch addresses the related i_inline_size staleness issue.