Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: validate orphan inode entry count<br /> <br /> f2fs_recover_orphan_inodes() trusts the orphan block entry_count when<br /> replaying orphan inodes from the checkpoint pack. A corrupted entry_count<br /> larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop read past the<br /> ino[] array and interpret footer or following data as inode numbers.<br /> <br /> On a crafted image, mounting an unpatched kernel can drive orphan recovery<br /> into f2fs_bug_on() and panic the kernel. Validate entry_count before<br /> consuming entries so corrupted checkpoint data fails the mount with<br /> -EFSCORRUPTED and requests fsck instead.<br /> <br /> Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be<br /> recorded in the superblock s_errors[] field. This gives fsck a persistent<br /> hint even though mount-time orphan recovery failure may leave no chance to<br /> persist SBI_NEED_FSCK through a checkpoint.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on f2fs_get_node_folio_ra()<br /> <br /> kernel BUG at fs/f2fs/file.c:845!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:f2fs_do_truncate_blocks+0x1115/0x1140 fs/f2fs/file.c:845<br /> Code: fc fc 90 0f 0b e8 8b 9d 9a fd 90 0f 0b e8 83 9d 9a fd 48 89 df 48 c7 c6 60 d1 1a 8c e8 54 f1 fc fc 90 0f 0b e8 6c 9d 9a fd 90 0b e8 64 9d 9a fd 90 0f 0b 90 e9 93 fd ff ff e8 56 9d 9a fd 90<br /> RSP: 0018:ffffc9000e4474c0 EFLAGS: 00010283<br /> RAX: ffffffff842b1d34 RBX: 0000000000000003 RCX: 0000000000100000<br /> RDX: ffffc9000f03a000 RSI: 0000000000035503 RDI: 0000000000035504<br /> RBP: ffffc9000e447608 R08: ffff8880123b0000 R09: 0000000000000002<br /> R10: 00000000fffffffe R11: 0000000000000002 R12: 0000000000000001<br /> R13: 0000000000000000 R14: 1ffff92001c88ea0 R15: 00000000ffff039c<br /> FS: 00007f7e02ee36c0(0000) GS:ffff88808c887000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ff0305c4000 CR3: 0000000012d4c000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c:882<br /> f2fs_truncate+0x471/0x7c0 fs/f2fs/file.c:940<br /> f2fs_evict_inode+0xa3f/0x1ac0 fs/f2fs/inode.c:907<br /> evict+0x61e/0xb10 fs/inode.c:841<br /> f2fs_fill_super+0x5f43/0x78f0 fs/f2fs/super.c:5224<br /> get_tree_bdev_flags+0x431/0x4f0 fs/super.c:1694<br /> vfs_get_tree+0x92/0x2a0 fs/super.c:1754<br /> fc_mount fs/namespace.c:1193 [inline]<br /> do_new_mount_fc fs/namespace.c:3758 [inline]<br /> do_new_mount+0x341/0xd30 fs/namespace.c:3834<br /> do_mount fs/namespace.c:4167 [inline]<br /> __do_sys_mount fs/namespace.c:4383 [inline]<br /> __se_sys_mount+0x31d/0x420 fs/namespace.c:4360<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> count = ADDRS_PER_PAGE(dn.node_folio, inode);<br /> <br /> count -= dn.ofs_in_node;<br /> f2fs_bug_on(sbi, count check whether it is inode|xnode

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: fix use-after-free in gfs2_qd_dealloc<br /> <br /> gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(),<br /> accesses the superblock object sdp through qd-&gt;qd_sbd after freeing qd.<br /> It does so to decrement sd_quota_count and wake up sd_kill_wait.<br /> <br /> However, by the time the RCU callback runs, gfs2_put_super() may have<br /> already freed sdp via free_sbd(). This can happen when<br /> gfs2_quota_cleanup() is called during unmount: it disposes of quota<br /> objects via call_rcu() and then waits on sd_kill_wait with a 60-second<br /> timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers<br /> additional qd_put() calls that schedule more RCU callbacks after the<br /> wait completes, gfs2_put_super() will proceed to free the superblock<br /> while RCU callbacks referencing it are still pending.<br /> <br /> Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure<br /> all pending RCU callbacks (including gfs2_qd_dealloc) have completed<br /> before the superblock is freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: nx - fix nx_crypto_ctx_exit argument<br /> <br /> nx_crypto_ctx_shash_exit calls nx_crypto_ctx_exit with crypto_shash_ctx(...)<br /> but crypto_shash_ctx gives a nx_crypto_ctx *, not a crypto_tfm *.<br /> <br /> Fix the type in nx_crypto_ctx_exit and drop the bogus crypto_tfm_ctx<br /> call.<br /> <br /> This fixes the following oops:<br /> <br /> BUG: Unable to handle kernel data access at 0xc0403effffffffc8<br /> Faulting instruction address: 0xc000000000396cb4<br /> Oops: Kernel access of bad area, sig: 11 [#15]<br /> Call Trace:<br /> nx_crypto_ctx_shash_exit+0x24/0x60<br /> crypto_shash_exit_tfm+0x28/0x40<br /> crypto_destroy_tfm+0x98/0x140<br /> crypto_exit_ahash_using_shash+0x20/0x40<br /> crypto_destroy_tfm+0x98/0x140<br /> hash_release+0x1c/0x30<br /> alg_sock_destruct+0x38/0x60<br /> __sk_destruct+0x48/0x2b0<br /> af_alg_release+0x58/0xb0<br /> __sock_release+0x68/0x150<br /> sock_close+0x20/0x40<br /> __fput+0x110/0x3a0<br /> sys_close+0x48/0xa0<br /> system_call_exception+0x140/0x2d0<br /> system_call_common+0xf4/0x258<br /> <br /> .. which came from hardlink(1) opportunistically using AF_ALG.<br /> <br /> The same problem exists with nx_crypto_ctx_skcipher_exit getting a context<br /> it wasn&amp;#39;t expecting, but apparently nobody hit that for years.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned()<br /> <br /> Drop a BUG_ON() that has been reachable since it was first added, way back<br /> in 2009, and instead use get_unaligned() to perform potentially-unaligned<br /> accesses.<br /> <br /> For a given store, KVM x86&amp;#39;s emulator tracks the entire value in the<br /> destination operand, x86_emulate_ctxt.dst. If the destination is memory,<br /> and the target splits multiple pages and/or is emulated MMIO, then KVM<br /> handles each fragment independently. E.g. on a page split starting at page<br /> offset 0xffc, KVM writes 4 bytes to the first page, then the remaining<br /> bytes to the second page, using ctxt-&gt;dst as the source for both (with<br /> appropriate offsets).<br /> <br /> If the destination splits a page *and* hits emulated MMIO on the second<br /> page, then KVM will complete the write to the first page, then emulate the<br /> MMIO access to the second page. If there is a datamatch-enabled ioeventfd<br /> at offset 0 of the second page, then KVM will process the remainder of the<br /> store as a potential ioeventfd signal.<br /> <br /> Putting it all together, if the guest emits a store that splits a page<br /> starting at page offset N, and the second page has a datamatch-enabled<br /> ioeventfd at offset 0, then KVM will check for datamatch using<br /> &amp;dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being<br /> 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires.<br /> <br /> E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8,<br /> all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON()<br /> fires due to @val being 4-byte aligned, but not 8-byte aligned.<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783!<br /> Oops: invalid opcode: 0000 [#1] SMP<br /> CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm]<br /> Call Trace:<br /> <br /> __kvm_io_bus_write+0x85/0xb0 [kvm]<br /> kvm_io_bus_write+0x53/0x80 [kvm]<br /> vcpu_mmio_write+0x66/0xf0 [kvm]<br /> emulator_read_write_onepage+0x12a/0x540 [kvm]<br /> emulator_read_write+0x109/0x2b0 [kvm]<br /> x86_emulate_insn+0x4f8/0xfb0 [kvm]<br /> x86_emulate_instruction+0x181/0x790 [kvm]<br /> kvm_mmu_page_fault+0x313/0x630 [kvm]<br /> vmx_handle_exit+0x18a/0x590 [kvm_intel]<br /> kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm]<br /> kvm_vcpu_ioctl+0x2d5/0x970 [kvm]<br /> __x64_sys_ioctl+0x8a/0xd0<br /> do_syscall_64+0xb7/0x890<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f19c931a9bf<br /> <br /> Modules linked in: kvm_intel kvm irqbypass<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM<br /> x86 doesn&amp;#39;t perform alignment checks on "normal" memory accesses at CPL0.<br /> Sadly, C99 ruins all the fun; while the x86 architecture plays nice,<br /> dereferencing an unaligned pointer directly is undefined behavior in C,<br /> e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level<br /> <br /> When recovering hugepages in the shadow MMU, verify that the base gfn of<br /> the shadow page is actually contained within the target memslot, *before*<br /> querying the max mapping level given the shadow page&amp;#39;s gfn. Failure to<br /> pre-check the validity of the gfn can lead to an out-of-bounds access to<br /> the slot&amp;#39;s lpage_info (which typically manifests as a host #PF because the<br /> lpage_info is vmalloc&amp;#39;d) if the guest creates a hugepage mapping (in its<br /> PTEs) that extends "below" the bounds of a memslot.<br /> <br /> When faulting in memory for a guest, and the size of the guest mapping is<br /> greater than KVM&amp;#39;s (current) max mapping, then KVM will create a "direct"<br /> shadow page (direct in that there are no gPTEs to shadow, and so the target<br /> gfn is a direct calculation given the base gfn of the shadow page). The<br /> hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB<br /> mappings when dirty logging generates the guest &gt; host mapping size case.<br /> When the 4KiB restriction is lifted, then KVM can replace the shadow page<br /> with a hugepage.<br /> <br /> But if KVM originally used a smaller mapping than the guest because the<br /> range of memory covered by the guest hugepage exceeds the bounds of a<br /> memslot, then KVM will link a direct shadow page with a gfn that is outside<br /> the bounds of the memslot being used to fault in memory. The rmap entry<br /> added for the leaf mapping is correct and within bounds, but the gfn of the<br /> leaf SPTE&amp;#39;s parent shadow page will be out of bounds.<br /> <br /> BUG: unable to handle page fault for address: ffffc90000806ffc<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm]<br /> Call Trace:<br /> <br /> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm]<br /> kvm_set_memslot+0x1ee/0x590 [kvm]<br /> kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm]<br /> kvm_vm_ioctl+0x9bf/0x15d0 [kvm]<br /> __x64_sys_ioctl+0x8a/0xd0<br /> do_syscall_64+0xb7/0xbb0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f21c0f1a9bf<br /> <br /> <br /> Don&amp;#39;t bother pre-checking the bounds of the potential hugepage, i.e. don&amp;#39;t<br /> check that e.g. sp-&gt;gfn + KVM_PAGES_PER_HPAGE(sp-&gt;role.level + 1) is also<br /> within the memslot, as the checks performed by kvm_mmu_max_mapping_level()<br /> are a superset of the basic bounds checks. I.e. pre-checking the full<br /> range would be a dubious micro-optimization.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix potential use-after-free in exfat_find_dir_entry()<br /> <br /> In exfat_find_dir_entry(), the buffer_head obtained from<br /> exfat_get_dentry() is released with brelse(bh) before the fall-through<br /> TYPE_EXTEND branch reads the directory entry through ep (which points<br /> into bh-&gt;b_data):<br /> <br /> brelse(bh);<br /> if (entry_type == TYPE_EXTEND) {<br /> ...<br /> len = exfat_extract_uni_name(ep, entry_uniname);<br /> ...<br /> }<br /> <br /> After brelse() drops our reference, nothing guarantees that the<br /> underlying page backing bh-&gt;b_data remains valid for the subsequent<br /> exfat_extract_uni_name() read. This is the same pattern fixed in<br /> commit fc961522ddbd ("exfat: Fix potential use after free in<br /> exfat_load_upcase_table()").<br /> <br /> Move brelse(bh) so it runs after ep is no longer dereferenced on<br /> each branch.<br /> <br /> Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y<br /> + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image<br /> (long filename with same-hash collisions forcing the TYPE_EXTEND path).<br /> With a debug-only invalidate_bdev() inserted between brelse(bh) and<br /> the ep read to make the stale-deref window deterministic, the<br /> unpatched kernel faults:<br /> <br /> BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0<br /> BUG: unable to handle page fault for address: ffff88801a5fa0c2<br /> Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI<br /> RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0<br /> <br /> With this patch applied, the same instrumented harness completes<br /> cleanly under the same sanitizer stack. I have not reproduced a<br /> crash on an uninstrumented kernel under ordinary reclaim; the<br /> instrumented A/B establishes the lifetime violation and that the<br /> patch closes it, not an unaided triggerability claim.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: use kvfree() for replaced sysctl write buffer<br /> <br /> proc_sys_call_handler() allocates its temporary sysctl buffer with<br /> kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since<br /> kvzalloc() may fall back to vmalloc() for large allocations, freeing<br /> that buffer with kfree() is wrong and can corrupt memory.<br /> <br /> Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc<br /> allocations.<br /> <br /> The bug was first flagged by an experimental analysis tool we are<br /> developing for kernel memory-management bugs while analyzing<br /> v6.13-rc1. The tool is still under development and is not yet publicly<br /> available. Manual inspection confirms that the bug is still<br /> present in v7.1-rc5.<br /> <br /> Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with<br /> KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the<br /> test tree also included the accompanying fix for the stale ret == 1<br /> check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines<br /> failslab injections to the proc_sys_call_handler() range, uses<br /> stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to<br /> /proc/sys/kernel/domainname from a task in the target cgroup. Under<br /> that setup, fail-nth=1 triggered the fault:<br /> <br /> BUG: unable to handle page fault for address: ffffeb0200024d48<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 SMP KASAN NOPTI<br /> CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:kfree+0x6e/0x510<br /> ...<br /> Call Trace:<br /> <br /> ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30<br /> __cgroup_bpf_run_filter_sysctl+0x74d/0xc30<br /> ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? __kvmalloc_node_noprof+0x345/0x870<br /> ? proc_sys_call_handler+0x250/0x480<br /> ? srso_return_thunk+0x5/0x5f<br /> proc_sys_call_handler+0x3a2/0x480<br /> ? __pfx_proc_sys_call_handler+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? selinux_file_permission+0x39f/0x500<br /> ? srso_return_thunk+0x5/0x5f<br /> ? lock_is_held_type+0x9e/0x120<br /> vfs_write+0x98e/0x1000<br /> ...<br /> <br /> <br /> With this fix applied on top of the same test setup, rerunning the<br /> reproducer with fail-nth=1 yields no corresponding Oops reports.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Avoid mounting the bdev pseudo-filesystem in userspace<br /> <br /> The bdev pseudo-filesystem is an internal kernel filesystem with which<br /> userspace should not interfere. Unregister it so that userspace cannot<br /> even attempt to mount it.<br /> <br /> This fixes a bug [1] that occurs when attempting to access files,<br /> because the system call move_mount() uses pointers declared in the<br /> inode_operations structure, which for the bdev pseudo-filesystem<br /> are always equal to 0. `inode-&gt;i_op = &amp;empty_iops;`<br /> <br /> [1]<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor instruction fetch in kernel mode<br /> #PF: error_code(0x0010) - not-present page<br /> PGD 23380067 P4D 23380067 PUD 23381067 PMD 0<br /> Oops: 0010 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 2 PID: 17125 Comm: syz-executor.0 Not tainted 6.1.155-syzkaller-00350-g84221fde2681 #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:0x0<br /> <br /> Call Trace:<br /> <br /> lookup_open.isra.0+0x700/0x1180 fs/namei.c:3460<br /> open_last_lookups fs/namei.c:3550 [inline]<br /> path_openat+0x953/0x2700 fs/namei.c:3780<br /> do_filp_open+0x1c5/0x410 fs/namei.c:3810<br /> do_sys_openat2+0x171/0x4d0 fs/open.c:1318<br /> do_sys_open fs/open.c:1334 [inline]<br /> __do_sys_openat fs/open.c:1350 [inline]<br /> __se_sys_openat fs/open.c:1345 [inline]<br /> __x64_sys_openat+0x13c/0x1f0 fs/open.c:1345<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<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: reject oversized group bitmap descriptors<br /> <br /> ocfs2_validate_gd_parent() only bounds bg_bits against the parent<br /> allocator&amp;#39;s chain geometry. A malicious descriptor can still claim a<br /> bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in<br /> the group descriptor block, so later bitmap scans and bit updates can run<br /> past bg_bitmap.<br /> <br /> Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent<br /> allocator type and reject descriptors whose bg_size or bg_bits exceed that<br /> capacity. Keep the existing chain geometry check so both the on-disk<br /> bitmap layout and the allocator metadata must agree before the descriptor<br /> is used.<br /> <br /> Validation reproduced this kernel report:<br /> KASAN use-after-free in _find_next_bit+0x7f/0xc0<br /> Read of size 8<br /> Call trace:<br /> dump_stack_lvl+0x66/0xa0 (?:?)<br /> print_report+0xd0/0x630 (?:?)<br /> _find_next_bit+0x7f/0xc0 (?:?)<br /> srso_alias_return_thunk+0x5/0xfbef5 (?:?)<br /> __virt_addr_valid+0x188/0x2f0 (?:?)<br /> kasan_report+0xe4/0x120 (?:?)<br /> ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375)<br /> ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457)<br /> ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86)<br /> ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786)<br /> ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886)<br /> get_page_from_freelist+0x70e/0x2370 (?:?)<br /> lock_release+0xc6/0x290 (?:?)<br /> do_raw_spin_unlock+0x9a/0x100 (?:?)<br /> kasan_unpoison+0x27/0x60 (?:?)<br /> __bfs+0x147/0x240 (?:?)<br /> get_page_from_freelist+0x83d/0x2370 (?:?)<br /> ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96)<br /> sched_domains_numa_masks_clear+0x70/0xd0 (?:?)<br /> check_irq_usage+0xe8/0xb70 (?:?)<br /> __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497)<br /> check_path+0x24/0x50 (?:?)<br /> rcu_is_watching+0x20/0x50 (?:?)<br /> check_prev_add+0xfd/0xd00 (?:?)<br /> ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?)<br /> __folio_batch_add_and_move+0x1f5/0x3d0 (?:?)<br /> ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?)<br /> filemap_add_folio+0x105/0x1f0 (?:?)<br /> ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043)<br /> ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?)<br /> down_write+0xf5/0x180 (?:?)<br /> ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?)<br /> __mark_inode_dirty+0x758/0x9a0 (?:?)<br /> inode_to_bdi+0x41/0x90 (?:?)<br /> balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?)<br /> generic_perform_write+0x252/0x440 (?:?)<br /> mnt_put_write_access_file+0x16/0x70 (?:?)<br /> file_update_time_flags+0xe4/0x200 (?:?)<br /> ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?)<br /> lock_acquire+0x184/0x2f0 (?:?)<br /> ksys_write+0xd2/0x170 (?:?)<br /> apparmor_file_permission+0xf5/0x310 (?:?)<br /> read_zero+0x8d/0x140 (?:?)<br /> lock_is_held_type+0x8f/0x100 (?:?)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: char: Fix use-after-free on probe error path<br /> <br /> rpmsg_chrdev_probe() stores the newly allocated eptdev in the default<br /> endpoint&amp;#39;s priv pointer before calling rpmsg_chrdev_eptdev_add(). If<br /> rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while<br /> the default endpoint may still dispatch callbacks with the stale priv<br /> pointer.<br /> <br /> Avoid publishing eptdev through the default endpoint until<br /> rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv<br /> pointer is published should be ignored by rpmsg_ept_cb(). Flow-control<br /> updates can hit rpmsg_ept_flow_cb() in the same window, so make both<br /> callbacks return success when priv is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove<br /> <br /> The driver allocates domain generic chips using<br /> irq_alloc_domain_generic_chips() during probe and sets up chained<br /> handlers using irq_set_chained_handler_and_data(). However, on driver<br /> removal, the generic chips are not freed and the chained handlers are<br /> not removed.<br /> <br /> The generic chips remain on the global gc_list and may later be accessed by<br /> generic interrupt chip suspend, resume, or shutdown callbacks after the<br /> driver has been removed, potentially resulting in a use-after-free and<br /> kernel crash.<br /> <br /> The chained handlers that were installed in probe for peripheral and<br /> syswake interrupts are also left dangling, which can lead to spurious<br /> interrupts accessing freed memory.<br /> <br /> Fix these issues by:<br /> <br /> - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain-&gt;flags, so the<br /> core code automatically removes generic chips when irq_domain_remove()<br /> is called<br /> <br /> - Clearing all chained handlers with NULL in pdc_intc_remove()