Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vivid: Change the siize of the composing<br /> <br /> syzkaller found a bug:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]<br /> BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705<br /> Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304<br /> <br /> CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:489<br /> kasan_report+0x143/0x180 mm/kasan/report.c:602<br /> kasan_check_range+0x282/0x290 mm/kasan/generic.c:189<br /> __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106<br /> tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]<br /> tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705<br /> vivid_fillbuff drivers/media/test-drivers/vivid/vivid-kthread-cap.c:470 [inline]<br /> vivid_thread_vid_cap_tick+0xf8e/0x60d0 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:629<br /> vivid_thread_vid_cap+0x8aa/0xf30 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:767<br /> kthread+0x7a9/0x920 kernel/kthread.c:464<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> The composition size cannot be larger than the size of fmt_cap_rect.<br /> So execute v4l2_rect_map_inside() even if has_compose_cap == 0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Restore context entry setup order for aliased devices<br /> <br /> Commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain")<br /> changed the context entry setup during domain attachment from a<br /> set-and-check policy to a clear-and-reset approach. This inadvertently<br /> introduced a regression affecting PCI aliased devices behind PCIe-to-PCI<br /> bridges.<br /> <br /> Specifically, keyboard and touchpad stopped working on several Apple<br /> Macbooks with below messages:<br /> <br /> kernel: platform pxa2xx-spi.3: Adding to iommu group 20<br /> kernel: input: Apple SPI Keyboard as<br /> /devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/input/input0<br /> kernel: DMAR: DRHD: handling fault status reg 3<br /> kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr<br /> 0xffffa000 [fault reason 0x06] PTE Read access is not set<br /> kernel: DMAR: DRHD: handling fault status reg 3<br /> kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr<br /> 0xffffa000 [fault reason 0x06] PTE Read access is not set<br /> kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00<br /> kernel: DMAR: DRHD: handling fault status reg 3<br /> kernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr<br /> 0xffffa000 [fault reason 0x06] PTE Read access is not set<br /> kernel: DMAR: DRHD: handling fault status reg 3<br /> kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00<br /> <br /> Fix this by restoring the previous context setup order.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (ftsteutates) Fix TOCTOU race in fts_read()<br /> <br /> In the fts_read() function, when handling hwmon_pwm_auto_channels_temp,<br /> the code accesses the shared variable data-&gt;fan_source[channel] twice<br /> without holding any locks. It is first checked against<br /> FTS_FAN_SOURCE_INVALID, and if the check passes, it is read again<br /> when used as an argument to the BIT() macro.<br /> <br /> This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition.<br /> Another thread executing fts_update_device() can modify the value of<br /> data-&gt;fan_source[channel] between the check and its use. If the value<br /> is changed to FTS_FAN_SOURCE_INVALID (0xff) during this window, the<br /> BIT() macro will be called with a large shift value (BIT(255)).<br /> A bit shift by a value greater than or equal to the type width is<br /> undefined behavior and can lead to a crash or incorrect values being<br /> returned to userspace.<br /> <br /> Fix this by reading data-&gt;fan_source[channel] into a local variable<br /> once, eliminating the race condition. Additionally, add a bounds check<br /> to ensure the value is less than BITS_PER_LONG before passing it to<br /> the BIT() macro, making the code more robust against undefined behavior.<br /> <br /> This possible bug was found by an experimental static analysis tool<br /> developed by our team.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on sit_bitmap_size<br /> <br /> w/ below testcase, resize will generate a corrupted image which<br /> contains inconsistent metadata, so when mounting such image, it<br /> will trigger kernel panic:<br /> <br /> touch img<br /> truncate -s $((512*1024*1024*1024)) img<br /> mkfs.f2fs -f img $((256*1024*1024))<br /> resize.f2fs -s -i img -t $((1024*1024*1024))<br /> mount img /mnt/f2fs<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/segment.h:863!<br /> Oops: invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490<br /> <br /> Call Trace:<br /> f2fs_build_segment_manager+0x11c3/0x2600<br /> f2fs_fill_super+0xe97/0x2840<br /> mount_bdev+0xf4/0x140<br /> legacy_get_tree+0x2b/0x50<br /> vfs_get_tree+0x29/0xd0<br /> path_mount+0x487/0xaf0<br /> __x64_sys_mount+0x116/0x150<br /> do_syscall_64+0x82/0x190<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fdbfde1bcfe<br /> <br /> The reaseon is:<br /> <br /> sit_i-&gt;bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum<br /> there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt<br /> is 4762, build_sit_entries() -&gt; current_sit_addr() tries to access<br /> out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap<br /> and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on().<br /> <br /> Let&amp;#39;s add sanity check in f2fs_sanity_check_ckpt() to avoid panic.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: prevent kernel warning due to negative i_nlink from corrupted image<br /> <br /> WARNING: CPU: 1 PID: 9426 at fs/inode.c:417 drop_nlink+0xac/0xd0<br /> home/cc/linux/fs/inode.c:417<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 9426 Comm: syz-executor568 Not tainted<br /> 6.14.0-12627-g94d471a4f428 #2 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417<br /> Code: 48 8b 5d 28 be 08 00 00 00 48 8d bb 70 07 00 00 e8 f9 67 e6 ff<br /> f0 48 ff 83 70 07 00 00 5b 5d e9 9a 12 82 ff e8 95 12 82 ff 90<br /> &amp;lt;0f&amp;gt; 0b 90 c7 45 48 ff ff ff ff 5b 5d e9 83 12 82 ff e8 fe 5f e6<br /> ff<br /> RSP: 0018:ffffc900026b7c28 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8239710f<br /> RDX: ffff888041345a00 RSI: ffffffff8239717b RDI: 0000000000000005<br /> RBP: ffff888054509ad0 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000000 R11: ffffffff9ab36f08 R12: ffff88804bb40000<br /> R13: ffff8880545091e0 R14: 0000000000008000 R15: ffff8880545091e0<br /> FS: 000055555d0c5880(0000) GS:ffff8880eb3e3000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f915c55b178 CR3: 0000000050d20000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> f2fs_i_links_write home/cc/linux/fs/f2fs/f2fs.h:3194 [inline]<br /> f2fs_drop_nlink+0xd1/0x3c0 home/cc/linux/fs/f2fs/dir.c:845<br /> f2fs_delete_entry+0x542/0x1450 home/cc/linux/fs/f2fs/dir.c:909<br /> f2fs_unlink+0x45c/0x890 home/cc/linux/fs/f2fs/namei.c:581<br /> vfs_unlink+0x2fb/0x9b0 home/cc/linux/fs/namei.c:4544<br /> do_unlinkat+0x4c5/0x6a0 home/cc/linux/fs/namei.c:4608<br /> __do_sys_unlink home/cc/linux/fs/namei.c:4654 [inline]<br /> __se_sys_unlink home/cc/linux/fs/namei.c:4652 [inline]<br /> __x64_sys_unlink+0xc5/0x110 home/cc/linux/fs/namei.c:4652<br /> do_syscall_x64 home/cc/linux/arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xc7/0x250 home/cc/linux/arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fb3d092324b<br /> Code: 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66<br /> 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 57 00 00 00 0f 05<br /> &amp;lt;48&amp;gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01<br /> 48<br /> RSP: 002b:00007ffdc232d938 EFLAGS: 00000206 ORIG_RAX: 0000000000000057<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb3d092324b<br /> RDX: 00007ffdc232d960 RSI: 00007ffdc232d960 RDI: 00007ffdc232d9f0<br /> RBP: 00007ffdc232d9f0 R08: 0000000000000001 R09: 00007ffdc232d7c0<br /> R10: 00000000fffffffd R11: 0000000000000206 R12: 00007ffdc232eaf0<br /> R13: 000055555d0cebb0 R14: 00007ffdc232d958 R15: 0000000000000001<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: only dirty folios when data journaling regular files<br /> <br /> fstest generic/388 occasionally reproduces a crash that looks as<br /> follows:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> Call Trace:<br /> <br /> ext4_block_zero_page_range+0x30c/0x380 [ext4]<br /> ext4_truncate+0x436/0x440 [ext4]<br /> ext4_process_orphan+0x5d/0x110 [ext4]<br /> ext4_orphan_cleanup+0x124/0x4f0 [ext4]<br /> ext4_fill_super+0x262d/0x3110 [ext4]<br /> get_tree_bdev_flags+0x132/0x1d0<br /> vfs_get_tree+0x26/0xd0<br /> vfs_cmd_create+0x59/0xe0<br /> __do_sys_fsconfig+0x4ed/0x6b0<br /> do_syscall_64+0x82/0x170<br /> ...<br /> <br /> This occurs when processing a symlink inode from the orphan list. The<br /> partial block zeroing code in the truncate path calls<br /> ext4_dirty_journalled_data() -&gt; folio_mark_dirty(). The latter calls<br /> mapping-&gt;a_ops-&gt;dirty_folio(), but symlink inodes are not assigned an<br /> a_ops vector in ext4, hence the crash.<br /> <br /> To avoid this problem, update the ext4_dirty_journalled_data() helper to<br /> only mark the folio dirty on regular files (for which a_ops is<br /> assigned). This also matches the journaling logic in the ext4_symlink()<br /> creation path, where ext4_handle_dirty_metadata() is called directly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix out of bounds punch offset<br /> <br /> Punching a hole with a start offset that exceeds max_end is not<br /> permitted and will result in a negative length in the<br /> truncate_inode_partial_folio() function while truncating the page cache,<br /> potentially leading to undesirable consequences.<br /> <br /> A simple reproducer:<br /> <br /> truncate -s 9895604649994 /mnt/foo<br /> xfs_io -c "pwrite 8796093022208 4096" /mnt/foo<br /> xfs_io -c "fpunch 8796093022213 25769803777" /mnt/foo<br /> <br /> kernel BUG at include/linux/highmem.h:275!<br /> Oops: invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 3 UID: 0 PID: 710 Comm: xfs_io Not tainted 6.15.0-rc3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:zero_user_segments.constprop.0+0xd7/0x110<br /> RSP: 0018:ffffc90001cf3b38 EFLAGS: 00010287<br /> RAX: 0000000000000005 RBX: ffffea0001485e40 RCX: 0000000000001000<br /> RDX: 000000000040b000 RSI: 0000000000000005 RDI: 000000000040b000<br /> RBP: 000000000040affb R08: ffff888000000000 R09: ffffea0000000000<br /> R10: 0000000000000003 R11: 00000000fffc7fc5 R12: 0000000000000005<br /> R13: 000000000040affb R14: ffffea0001485e40 R15: ffff888031cd3000<br /> FS: 00007f4f63d0b780(0000) GS:ffff8880d337d000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000001ae0b038 CR3: 00000000536aa000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> truncate_inode_partial_folio+0x3dd/0x620<br /> truncate_inode_pages_range+0x226/0x720<br /> ? bdev_getblk+0x52/0x3e0<br /> ? ext4_get_group_desc+0x78/0x150<br /> ? crc32c_arch+0xfd/0x180<br /> ? __ext4_get_inode_loc+0x18c/0x840<br /> ? ext4_inode_csum+0x117/0x160<br /> ? jbd2_journal_dirty_metadata+0x61/0x390<br /> ? __ext4_handle_dirty_metadata+0xa0/0x2b0<br /> ? kmem_cache_free+0x90/0x5a0<br /> ? jbd2_journal_stop+0x1d5/0x550<br /> ? __ext4_journal_stop+0x49/0x100<br /> truncate_pagecache_range+0x50/0x80<br /> ext4_truncate_page_cache_block_range+0x57/0x3a0<br /> ext4_punch_hole+0x1fe/0x670<br /> ext4_fallocate+0x792/0x17d0<br /> ? __count_memcg_events+0x175/0x2a0<br /> vfs_fallocate+0x121/0x560<br /> ksys_fallocate+0x51/0xc0<br /> __x64_sys_fallocate+0x24/0x40<br /> x64_sys_call+0x18d2/0x4170<br /> do_syscall_64+0xa7/0x220<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Fix this by filtering out cases where the punching start offset exceeds<br /> max_end.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: inline: fix len overflow in ext4_prepare_inline_data<br /> <br /> When running the following code on an ext4 filesystem with inline_data<br /> feature enabled, it will lead to the bug below.<br /> <br /> fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666);<br /> ftruncate(fd, 30);<br /> pwrite(fd, "a", 1, (1UL i_inline_size);<br /> <br /> at ext4_write_inline_data.<br /> <br /> Fix it by using a loff_t type for the len parameter in<br /> ext4_prepare_inline_data instead of an unsigned int.<br /> <br /> [ 44.545164] ------------[ cut here ]------------<br /> [ 44.545530] kernel BUG at fs/ext4/inline.c:240!<br /> [ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> [ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb<br /> [ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100<br /> [ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49<br /> [ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216<br /> [ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006<br /> [ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738<br /> [ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000<br /> [ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000<br /> [ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738<br /> [ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000<br /> [ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0<br /> [ 44.546523] PKRU: 55555554<br /> [ 44.546523] Call Trace:<br /> [ 44.546523] <br /> [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0<br /> [ 44.546523] generic_perform_write+0x17e/0x270<br /> [ 44.546523] ext4_buffered_write_iter+0xc8/0x170<br /> [ 44.546523] vfs_write+0x2be/0x3e0<br /> [ 44.546523] __x64_sys_pwrite64+0x6d/0xc0<br /> [ 44.546523] do_syscall_64+0x6a/0xf0<br /> [ 44.546523] ? __wake_up+0x89/0xb0<br /> [ 44.546523] ? xas_find+0x72/0x1c0<br /> [ 44.546523] ? next_uptodate_folio+0x317/0x330<br /> [ 44.546523] ? set_pte_range+0x1a6/0x270<br /> [ 44.546523] ? filemap_map_pages+0x6ee/0x840<br /> [ 44.546523] ? ext4_setattr+0x2fa/0x750<br /> [ 44.546523] ? do_pte_missing+0x128/0xf70<br /> [ 44.546523] ? security_inode_post_setattr+0x3e/0xd0<br /> [ 44.546523] ? ___pte_offset_map+0x19/0x100<br /> [ 44.546523] ? handle_mm_fault+0x721/0xa10<br /> [ 44.546523] ? do_user_addr_fault+0x197/0x730<br /> [ 44.546523] ? do_syscall_64+0x76/0xf0<br /> [ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60<br /> [ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90<br /> [ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d<br /> [ 44.546523] RIP: 0033:0x7f42999c6687<br /> [ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff<br /> [ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012<br /> [ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687<br /> [ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003<br /> [ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000<br /> [ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: avoid kernel BUG for encrypted inode with unaligned file size<br /> <br /> The generic/397 test hits a BUG_ON for the case of encrypted inode with<br /> unaligned file size (for example, 33K or 1K):<br /> <br /> [ 877.737811] run fstests generic/397 at 2025-01-03 12:34:40<br /> [ 877.875761] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 877.876130] libceph: client4614 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 877.991965] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 877.992334] libceph: client4617 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 878.017234] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 878.017594] libceph: client4620 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 878.031394] xfs_io (pid 18988) is setting deprecated v1 encryption policy; recommend upgrading to v2.<br /> [ 878.054528] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 878.054892] libceph: client4623 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 878.070287] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 878.070704] libceph: client4626 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 878.264586] libceph: mon0 (2)127.0.0.1:40674 session established<br /> [ 878.265258] libceph: client4629 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949<br /> [ 878.374578] -----------[ cut here ]------------<br /> [ 878.374586] kernel BUG at net/ceph/messenger.c:1070!<br /> [ 878.375150] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 878.378145] CPU: 2 UID: 0 PID: 4759 Comm: kworker/2:9 Not tainted 6.13.0-rc5+ #1<br /> [ 878.378969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 878.380167] Workqueue: ceph-msgr ceph_con_workfn<br /> [ 878.381639] RIP: 0010:ceph_msg_data_cursor_init+0x42/0x50<br /> [ 878.382152] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90<br /> [ 878.383928] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287<br /> [ 878.384447] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000<br /> [ 878.385129] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378<br /> [ 878.385839] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000<br /> [ 878.386539] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030<br /> [ 878.387203] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001<br /> [ 878.387877] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000<br /> [ 878.388663] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 878.389212] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0<br /> [ 878.389921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 878.390620] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 878.391307] PKRU: 55555554<br /> [ 878.391567] Call Trace:<br /> [ 878.391807] <br /> [ 878.392021] ? show_regs+0x71/0x90<br /> [ 878.392391] ? die+0x38/0xa0<br /> [ 878.392667] ? do_trap+0xdb/0x100<br /> [ 878.392981] ? do_error_trap+0x75/0xb0<br /> [ 878.393372] ? ceph_msg_data_cursor_init+0x42/0x50<br /> [ 878.393842] ? exc_invalid_op+0x53/0x80<br /> [ 878.394232] ? ceph_msg_data_cursor_init+0x42/0x50<br /> [ 878.394694] ? asm_exc_invalid_op+0x1b/0x20<br /> [ 878.395099] ? ceph_msg_data_cursor_init+0x42/0x50<br /> [ 878.395583] ? ceph_con_v2_try_read+0xd16/0x2220<br /> [ 878.396027] ? _raw_spin_unlock+0xe/0x40<br /> [ 878.396428] ? raw_spin_rq_unlock+0x10/0x40<br /> [ 878.396842] ? finish_task_switch.isra.0+0x97/0x310<br /> [ 878.397338] ? __schedule+0x44b/0x16b0<br /> [ 878.397738] ceph_con_workfn+0x326/0x750<br /> [ 878.398121] process_one_work+0x188/0x3d0<br /> [ 878.398522] ? __pfx_worker_thread+0x10/0x10<br /> [ 878.398929] worker_thread+0x2b5/0x3c0<br /> [ 878.399310] ? __pfx_worker_thread+0x10/0x10<br /> [ 878.399727] kthread+0xe1/0x120<br /> [ 878.400031] ? __pfx_kthread+0x10/0x10<br /> [ 878.400431] ret_from_fork+0x43/0x70<br /> [ 878.400771] ? __pfx_kthread+0x10/0x10<br /> [ 878.401127] ret_from_fork_asm+0x1a/0x30<br /> [ 878.401543] <br /> [ 878.401760] Modules l<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: remove tag set when second admin queue config fails<br /> <br /> Commit 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure<br /> concatenation") modified nvme_tcp_setup_ctrl() to call<br /> nvme_tcp_configure_admin_queue() twice. The first call prepares for<br /> DH-CHAP negotitation, and the second call is required for secure<br /> concatenation. However, this change triggered BUG KASAN slab-use-after-<br /> free in blk_mq_queue_tag_busy_iter(). This BUG can be recreated by<br /> repeating the blktests test case nvme/063 a few times [1].<br /> <br /> When the BUG happens, nvme_tcp_create_ctrl() fails in the call chain<br /> below:<br /> <br /> nvme_tcp_create_ctrl()<br /> nvme_tcp_alloc_ctrl() new=true ... Alloc nvme_tcp_ctrl and admin_tag_set<br /> nvme_tcp_setup_ctrl() new=true<br /> nvme_tcp_configure_admin_queue() new=true ... Succeed<br /> nvme_alloc_admin_tag_set() ... Alloc the tag set for admin_tag_set<br /> nvme_stop_keep_alive()<br /> nvme_tcp_teardown_admin_queue() remove=false<br /> nvme_tcp_configure_admin_queue() new=false<br /> nvme_tcp_alloc_admin_queue() ... Fail, but do not call nvme_remove_admin_tag_set()<br /> nvme_uninit_ctrl()<br /> nvme_put_ctrl() ... Free up the nvme_tcp_ctrl and admin_tag_set<br /> <br /> The first call of nvme_tcp_configure_admin_queue() succeeds with<br /> new=true argument. The second call fails with new=false argument. This<br /> second call does not call nvme_remove_admin_tag_set() on failure, due to<br /> the new=false argument. Then the admin tag set is not removed. However,<br /> nvme_tcp_create_ctrl() assumes that nvme_tcp_setup_ctrl() would call<br /> nvme_remove_admin_tag_set(). Then it frees up struct nvme_tcp_ctrl which<br /> has admin_tag_set field. Later on, the timeout handler accesses the<br /> admin_tag_set field and causes the BUG KASAN slab-use-after-free.<br /> <br /> To not leave the admin tag set, call nvme_remove_admin_tag_set() when<br /> the second nvme_tcp_configure_admin_queue() call fails. Do not return<br /> from nvme_tcp_setup_ctrl() on failure. Instead, jump to "destroy_admin"<br /> go-to label to call nvme_tcp_teardown_admin_queue() which calls<br /> nvme_remove_admin_tag_set().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> configfs-tsm-report: Fix NULL dereference of tsm_ops<br /> <br /> Unlike sysfs, the lifetime of configfs objects is controlled by<br /> userspace. There is no mechanism for the kernel to find and delete all<br /> created config-items. Instead, the configfs-tsm-report mechanism has an<br /> expectation that tsm_unregister() can happen at any time and cause<br /> established config-item access to start failing.<br /> <br /> That expectation is not fully satisfied. While tsm_report_read(),<br /> tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail<br /> if tsm_ops have been unregistered, tsm_report_privlevel_store()<br /> tsm_report_provider_show() fail to check for ops registration. Add the<br /> missing checks for tsm_ops having been removed.<br /> <br /> Now, in supporting the ability for tsm_unregister() to always succeed,<br /> it leaves the problem of what to do with lingering config-items. The<br /> expectation is that the admin that arranges for the -&gt;remove() (unbind)<br /> of the ${tsm_arch}-guest driver is also responsible for deletion of all<br /> open config-items. Until that deletion happens, -&gt;probe() (reload /<br /> bind) of the ${tsm_arch}-guest driver fails.<br /> <br /> This allows for emergency shutdown / revocation of attestation<br /> interfaces, and requires coordinated restart.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction<br /> <br /> The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last<br /> deref") simplified cm_id resource management by freeing cm_id once all<br /> references to the cm_id were removed. The references are removed either<br /> upon completion of iw_cm event handlers or when the application destroys<br /> the cm_id. This commit introduced the use-after-free condition where<br /> cm_id_private object could still be in use by event handler works during<br /> the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a<br /> use-after-free related to destroying CM IDs") addressed this use-after-<br /> free by flushing all pending works at the cm_id destruction.<br /> <br /> However, still another use-after-free possibility remained. It happens<br /> with the work objects allocated for each cm_id_priv within<br /> alloc_work_entries() during cm_id creation, and subsequently freed in<br /> dealloc_work_entries() once all references to the cm_id are removed.<br /> If the cm_id&amp;#39;s last reference is decremented in the event handler work,<br /> the work object for the work itself gets removed, and causes the use-<br /> after-free BUG below:<br /> <br /> BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250<br /> Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091<br /> <br /> CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014<br /> Workqueue: 0x0 (iw_cm_wq)<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6a/0x90<br /> print_report+0x174/0x554<br /> ? __virt_addr_valid+0x208/0x430<br /> ? __pwq_activate_work+0x1ff/0x250<br /> kasan_report+0xae/0x170<br /> ? __pwq_activate_work+0x1ff/0x250<br /> __pwq_activate_work+0x1ff/0x250<br /> pwq_dec_nr_in_flight+0x8c5/0xfb0<br /> process_one_work+0xc11/0x1460<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? assign_work+0x16c/0x240<br /> worker_thread+0x5ef/0xfd0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x3b0/0x770<br /> ? __pfx_kthread+0x10/0x10<br /> ? rcu_is_watching+0x11/0xb0<br /> ? _raw_spin_unlock_irq+0x24/0x50<br /> ? rcu_is_watching+0x11/0xb0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x70<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 147416:<br /> kasan_save_stack+0x2c/0x50<br /> kasan_save_track+0x10/0x30<br /> __kasan_kmalloc+0xa6/0xb0<br /> alloc_work_entries+0xa9/0x260 [iw_cm]<br /> iw_cm_connect+0x23/0x4a0 [iw_cm]<br /> rdma_connect_locked+0xbfd/0x1920 [rdma_cm]<br /> nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma]<br /> cma_cm_event_handler+0xae/0x320 [rdma_cm]<br /> cma_work_handler+0x106/0x1b0 [rdma_cm]<br /> process_one_work+0x84f/0x1460<br /> worker_thread+0x5ef/0xfd0<br /> kthread+0x3b0/0x770<br /> ret_from_fork+0x30/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 147091:<br /> kasan_save_stack+0x2c/0x50<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x37/0x60<br /> __kasan_slab_free+0x4b/0x70<br /> kfree+0x13a/0x4b0<br /> dealloc_work_entries+0x125/0x1f0 [iw_cm]<br /> iwcm_deref_id+0x6f/0xa0 [iw_cm]<br /> cm_work_handler+0x136/0x1ba0 [iw_cm]<br /> process_one_work+0x84f/0x1460<br /> worker_thread+0x5ef/0xfd0<br /> kthread+0x3b0/0x770<br /> ret_from_fork+0x30/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x2c/0x50<br /> kasan_record_aux_stack+0xa3/0xb0<br /> __queue_work+0x2ff/0x1390<br /> queue_work_on+0x67/0xc0<br /> cm_event_handler+0x46a/0x820 [iw_cm]<br /> siw_cm_upcall+0x330/0x650 [siw]<br /> siw_cm_work_handler+0x6b9/0x2b20 [siw]<br /> process_one_work+0x84f/0x1460<br /> worker_thread+0x5ef/0xfd0<br /> kthread+0x3b0/0x770<br /> ret_from_fork+0x30/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> This BUG is reproducible by repeating the blktests test case nvme/061<br /> for the rdma transport and the siw driver.<br /> <br /> To avoid the use-after-free of cm_id_private work objects, ensure that<br /> the last reference to the cm_id is decremented not in the event handler<br /> works, but in the cm_id destruction context. For that purpose, mo<br /> ---truncated---