Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vmw_balloon: indicate success when effectively deflating during migration<br /> <br /> When migrating a balloon page, we first deflate the old page to then<br /> inflate the new page.<br /> <br /> However, if inflating the new page succeeded, we effectively deflated the<br /> old page, reducing the balloon size.<br /> <br /> In that case, the migration actually worked: similar to migrating+<br /> immediately deflating the new page. The old page will be freed back to<br /> the buddy.<br /> <br /> Right now, the core will leave the page be marked as isolated (as we<br /> returned an error). When later trying to putback that page, we will run<br /> into the WARN_ON_ONCE() in balloon_page_putback().<br /> <br /> That handling was changed in commit 3544c4faccb8 ("mm/balloon_compaction:<br /> stop using __ClearPageMovable()"); before that change, we would have<br /> tolerated that way of handling it.<br /> <br /> To fix it, let&amp;#39;s just return 0 in that case, making the core effectively<br /> just clear the "isolated" flag + freeing it back to the buddy as if the<br /> migration succeeded. Note that the new page will also get freed when the<br /> core puts the last reference.<br /> <br /> Note that this also makes it all be more consistent: we will no longer<br /> unisolate the page in the balloon driver while keeping it marked as being<br /> isolated in migration core.<br /> <br /> This was found by code inspection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> most: usb: hdm_probe: Fix calling put_device() before device initialization<br /> <br /> The early error path in hdm_probe() can jump to err_free_mdev before<br /> &amp;mdev-&gt;dev has been initialized with device_initialize(). Calling<br /> put_device(&amp;mdev-&gt;dev) there triggers a device core WARN and ends up<br /> invoking kref_put(&amp;kobj-&gt;kref, kobject_release) on an uninitialized<br /> kobject.<br /> <br /> In this path the private struct was only kmalloc&amp;#39;ed and the intended<br /> release is effectively kfree(mdev) anyway, so free it directly instead<br /> of calling put_device() on an uninitialized device.<br /> <br /> This removes the WARNING and fixes the pre-initialization error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hung_task: fix warnings caused by unaligned lock pointers<br /> <br /> The blocker tracking mechanism assumes that lock pointers are at least<br /> 4-byte aligned to use their lower bits for type encoding.<br /> <br /> However, as reported by Eero Tamminen, some architectures like m68k<br /> only guarantee 2-byte alignment of 32-bit values. This breaks the<br /> assumption and causes two related WARN_ON_ONCE checks to trigger.<br /> <br /> To fix this, the runtime checks are adjusted to silently ignore any lock<br /> that is not 4-byte aligned, effectively disabling the feature in such<br /> cases and avoiding the related warnings.<br /> <br /> Thanks to Geert Uytterhoeven for bisecting!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: avoid infinite loops due to corrupted subpage compact indexes<br /> <br /> Robert reported an infinite loop observed by two crafted images.<br /> <br /> The root cause is that `clusterofs` can be larger than `lclustersize`<br /> for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:<br /> <br /> blocksize = lclustersize = 512 lcn = 6 clusterofs = 515<br /> <br /> Move the corresponding check for full compress indexes to<br /> `z_erofs_load_lcluster_from_disk()` to also cover subpage compact<br /> compress indexes.<br /> <br /> It also fixes the position of `m-&gt;type &gt;= Z_EROFS_LCLUSTER_TYPE_MAX`<br /> check, since it should be placed right after<br /> `z_erofs_load_{compact,full}_lcluster()`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup<br /> <br /> In fastrpc_map_lookup, dma_buf_get is called to obtain a reference to<br /> the dma_buf for comparison purposes. However, this reference is never<br /> released when the function returns, leading to a dma_buf memory leak.<br /> <br /> Fix this by adding dma_buf_put before returning from the function,<br /> ensuring that the temporarily acquired reference is properly released<br /> regardless of whether a matching map is found.<br /> <br /> Rule: add