Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: tegra124-emc: Fix dll_change check<br /> <br /> The code checking whether the specified memory timing enables DLL<br /> in the EMRS register was reversed. DLL is enabled if bit A0 is low.<br /> Fix the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine<br /> <br /> ksmbd_crypt_message() sets a NULL completion callback on AEAD requests<br /> and does not handle the -EINPROGRESS return code from async hardware<br /> crypto engines like the Qualcomm Crypto Engine (QCE). When QCE returns<br /> -EINPROGRESS, ksmbd treats it as an error and immediately frees the<br /> request while the hardware DMA operation is still in flight. The DMA<br /> completion callback then dereferences freed memory, causing a NULL<br /> pointer crash:<br /> <br /> pc : qce_skcipher_done+0x24/0x174<br /> lr : vchan_complete+0x230/0x27c<br /> ...<br /> el1h_64_irq+0x68/0x6c<br /> ksmbd_free_work_struct+0x20/0x118 [ksmbd]<br /> ksmbd_exit_file_cache+0x694/0xa4c [ksmbd]<br /> <br /> Use the standard crypto_wait_req() pattern with crypto_req_done() as<br /> the completion callback, matching the approach used by the SMB client<br /> in fs/smb/client/smb2ops.c. This properly handles both synchronous<br /> engines (immediate return) and async engines (-EINPROGRESS followed<br /> by callback notification).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi/capsule-loader: fix incorrect sizeof in phys array reallocation<br /> <br /> The krealloc() call for cap_info-&gt;phys in __efi_capsule_setup_info() uses<br /> sizeof(phys_addr_t *) instead of sizeof(phys_addr_t), which might be<br /> causing an undersized allocation.<br /> <br /> The allocation is also inconsistent with the initial array allocation in<br /> efi_capsule_open() that allocates one entry with sizeof(phys_addr_t),<br /> and the efi_capsule_write() function that stores phys_addr_t values (not<br /> pointers) via page_to_phys().<br /> <br /> On 64-bit systems where sizeof(phys_addr_t) == sizeof(phys_addr_t *), this<br /> goes unnoticed. On 32-bit systems with PAE where phys_addr_t is 64-bit but<br /> pointers are 32-bit, this allocates half the required space, which might<br /> lead to a heap buffer overflow when storing physical addresses.<br /> <br /> This is similar to the bug fixed in commit fccfa646ef36 ("efi/capsule-loader:<br /> fix incorrect allocation size") which fixed the same issue at the initial<br /> allocation site.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: prevent NULL pointer dereference during unmount<br /> <br /> When flushing out outstanding glock work during an unmount, gfs2_log_flush()<br /> can be called when sdp-&gt;sd_jdesc has already been deallocated and sdp-&gt;sd_jdesc<br /> is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in<br /> gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it<br /> missed the sdp-&gt;sd_jdesc dereference in gfs2_log_release(). Fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: add some missing log locking<br /> <br /> Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(),<br /> gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp-&gt;sd_log_flush_lock,<br /> but these functions require exclusion against concurrent transactions.<br /> <br /> To fix that, add a non-locking __gfs2_log_flush() function. Then, in<br /> gfs2_logd(), take sdp-&gt;sd_log_flush_lock before calling the above mentioned log<br /> flushing functions and __gfs2_log_flush().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> quota: Fix race of dquot_scan_active() with quota deactivation<br /> <br /> dquot_scan_active() can race with quota deactivation in<br /> quota_release_workfn() like:<br /> <br /> CPU0 (quota_release_workfn) CPU1 (dquot_scan_active)<br /> ============================== ==============================<br /> spin_lock(&amp;dq_list_lock);<br /> list_replace_init(<br /> &amp;releasing_dquots, &amp;rls_head);<br /> /* dquot X on rls_head,<br /> dq_count == 0,<br /> DQ_ACTIVE_B still set */<br /> spin_unlock(&amp;dq_list_lock);<br /> synchronize_srcu(&amp;dquot_srcu);<br /> spin_lock(&amp;dq_list_lock);<br /> list_for_each_entry(dquot,<br /> &amp;inuse_list, dq_inuse) {<br /> /* finds dquot X */<br /> dquot_active(X) -&gt; true<br /> atomic_inc(&amp;X-&gt;dq_count);<br /> }<br /> spin_unlock(&amp;dq_list_lock);<br /> spin_lock(&amp;dq_list_lock);<br /> dquot = list_first_entry(&amp;rls_head);<br /> WARN_ON_ONCE(atomic_read(&amp;dquot-&gt;dq_count));<br /> <br /> The problem is not only a cosmetic one as under memory pressure the<br /> caller of dquot_scan_active() can end up working on freed dquot.<br /> <br /> Fix the problem by making sure the dquot is removed from releasing list<br /> when we acquire a reference to it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc/tegra: cbb: Fix incorrect ARRAY_SIZE in fabric lookup tables<br /> <br /> Fix incorrect ARRAY_SIZE usage in fabric lookup tables which could<br /> cause out-of-bounds access during target timeout lookup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2/dlm: validate qr_numregions in dlm_match_regions()<br /> <br /> Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()".<br /> <br /> In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION<br /> network message is used to drive loops over the qr_regions buffer without<br /> sufficient validation. This series fixes two issues:<br /> <br /> - Patch 1 adds a bounds check to reject messages where qr_numregions<br /> exceeds O2NM_MAX_REGIONS. The o2net layer only validates message<br /> byte length; it does not constrain field values, so a crafted message<br /> can set qr_numregions up to 255 and trigger out-of-bounds reads past<br /> the 1024-byte qr_regions buffer.<br /> <br /> - Patch 2 fixes an off-by-one in the local-vs-remote comparison loop,<br /> which uses &amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Fix off-by-one in check_imm signed range check<br /> <br /> check_imm(bits, imm) is used in the arm64 BPF JIT to verify that<br /> a branch displacement (in arm64 instruction units) fits into the<br /> signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding<br /> before it is handed to the encoder. The macro currently tests for<br /> (imm &gt; 0 &amp;&amp; imm &gt;&gt; bits) || (imm &gt; bits) which admits<br /> values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A<br /> signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check<br /> admits one extra bit of range on each side.<br /> <br /> In particular, for check_imm19(), values in [2^18, 2^19) slip past<br /> the check but do not fit into the 19-bit signed imm19 field of<br /> B.cond. aarch64_insn_encode_immediate() then masks the raw value<br /> into the 19-bit field, setting bit 18 (the sign bit) and flipping<br /> a forward branch into a backward one. Same class of issue exists<br /> for check_imm26() and the B/BL encoding. Shift by (bits - 1)<br /> instead of bits so the actual signed N-bit range is enforced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal<br /> <br /> CXL is linked before fwctl in drivers/Makefile. Both use `module_init, so<br /> `cxl_pci_driver_init()` runs first. When `cxl_pci_probe()` calls<br /> `fwctl_register()` and then `device_add()`, fwctl_class is not yet<br /> registered because fwctl_init() hasn&amp;#39;t run, causing `class_to_subsys()` to<br /> return NULL and skip knode_class initialization.<br /> <br /> On device removal, `class_to_subsys()` returns non-NULL, and<br /> `device_del()` calls `klist_del()` on the uninitialized knode, triggering<br /> a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix listxattr handling when the buffer is full<br /> <br /> [BUG]<br /> If an OCFS2 inode has both inline and block-based xattrs, listxattr()<br /> can return a size larger than the caller&amp;#39;s buffer when the inline names<br /> consume that buffer exactly.<br /> <br /> kernel BUG at mm/usercopy.c:102!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102<br /> Call Trace:<br /> __check_heap_object+0xe3/0x120 mm/slub.c:8243<br /> check_heap_object mm/usercopy.c:196 [inline]<br /> __check_object_size mm/usercopy.c:250 [inline]<br /> __check_object_size+0x5c5/0x780 mm/usercopy.c:215<br /> check_object_size include/linux/ucopysize.h:22 [inline]<br /> check_copy_size include/linux/ucopysize.h:59 [inline]<br /> copy_to_user include/linux/uaccess.h:219 [inline]<br /> listxattr+0xb0/0x170 fs/xattr.c:926<br /> filename_listxattr fs/xattr.c:958 [inline]<br /> path_listxattrat+0x137/0x320 fs/xattr.c:988<br /> __do_sys_listxattr fs/xattr.c:1001 [inline]<br /> __se_sys_listxattr fs/xattr.c:998 [inline]<br /> __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998<br /> ...<br /> <br /> [CAUSE]<br /> Commit 936b8834366e ("ocfs2: Refactor xattr list and remove<br /> ocfs2_xattr_handler().") replaced the old per-handler list accounting<br /> with ocfs2_xattr_list_entry(), but it kept using size == 0 to detect<br /> probe mode.<br /> <br /> That assumption stops being true once ocfs2_listxattr() finishes the<br /> inline-xattr pass. If the inline names fill the caller buffer exactly,<br /> the block-xattr pass runs with a non-NULL buffer and a remaining size of<br /> zero. ocfs2_xattr_list_entry() then skips the bounds check, keeps<br /> counting block names, and returns a positive size larger than the<br /> supplied buffer.<br /> <br /> [FIX]<br /> Detect probe mode by testing whether the destination buffer pointer is<br /> NULL instead of whether the remaining size is zero.<br /> <br /> That restores the pre-refactor behavior and matches the OCFS2 getxattr<br /> helpers. Once the remaining buffer reaches zero while more names are<br /> left, the block-xattr pass now returns -ERANGE instead of reporting a<br /> size larger than the allocated list buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: validate bg_bits during freefrag scan<br /> <br /> [BUG]<br /> A crafted filesystem can trigger an out-of-bounds bitmap walk when<br /> OCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT.<br /> <br /> BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline]<br /> BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]<br /> BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline]<br /> BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline]<br /> BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline]<br /> BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline]<br /> BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754<br /> Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xd1/0x650 mm/kasan/report.c:482<br /> kasan_report+0xfb/0x140 mm/kasan/report.c:595<br /> check_region_inline mm/kasan/generic.c:186 [inline]<br /> kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200<br /> __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31<br /> instrument_atomic_read include/linux/instrumented.h:68 [inline]<br /> _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]<br /> test_bit_le include/asm-generic/bitops/le.h:21 [inline]<br /> ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline]<br /> ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline]<br /> ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline]<br /> ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754<br /> ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828<br /> ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583<br /> ...<br /> <br /> [CAUSE]<br /> ocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as the<br /> bitmap scan limit. The coherent path reads group descriptors through<br /> ocfs2_read_group_descriptor(), which validates the descriptor before<br /> use. The non-coherent path uses ocfs2_read_blocks_sync() instead and<br /> skips that validation, so an impossible bg_bits value can drive the<br /> bitmap walk past the end of the block.<br /> <br /> [FIX]<br /> Compute the bitmap capacity from the filesystem format with<br /> ocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds<br /> that limit, and clamp the scan to the computed capacity. This keeps the<br /> freefrag report going while avoiding reads beyond the buffer.