Vulnerabilities

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 />

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.

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.

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---

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---

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.

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.

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.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var<br /> <br /> If fb_add_videomode() in fb_set_var() fails to allocate memory for<br /> fb_videomode, later it may lead to a null-ptr dereference in<br /> fb_videomode_to_var(), as the fb_info is registered while not having the<br /> mode in modelist that is expected to be there, i.e. the one that is<br /> described in fb_info-&gt;var.<br /> <br /> ================================================================<br /> general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901<br /> Call Trace:<br /> display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929<br /> fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071<br /> resize_screen drivers/tty/vt/vt.c:1176 [inline]<br /> vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263<br /> fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720<br /> fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776<br /> do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128<br /> fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203<br /> vfs_ioctl fs/ioctl.c:48 [inline]<br /> __do_sys_ioctl fs/ioctl.c:753 [inline]<br /> __se_sys_ioctl fs/ioctl.c:739 [inline]<br /> __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739<br /> do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> ================================================================<br /> <br /> The reason is that fb_info-&gt;var is being modified in fb_set_var(), and<br /> then fb_videomode_to_var() is called. If it fails to add the mode to<br /> fb_info-&gt;modelist, fb_set_var() returns error, but does not restore the<br /> old value of fb_info-&gt;var. Restore fb_info-&gt;var on failure the same way<br /> it is done earlier in the function.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var<br /> <br /> If fb_add_videomode() in do_register_framebuffer() fails to allocate<br /> memory for fb_videomode, it will later lead to a null-ptr dereference in<br /> fb_videomode_to_var(), as the fb_info is registered while not having the<br /> mode in modelist that is expected to be there, i.e. the one that is<br /> described in fb_info-&gt;var.<br /> <br /> ================================================================<br /> general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901<br /> Call Trace:<br /> display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929<br /> fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071<br /> resize_screen drivers/tty/vt/vt.c:1176 [inline]<br /> vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263<br /> fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720<br /> fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776<br /> do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128<br /> fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203<br /> vfs_ioctl fs/ioctl.c:48 [inline]<br /> __do_sys_ioctl fs/ioctl.c:753 [inline]<br /> __se_sys_ioctl fs/ioctl.c:739 [inline]<br /> __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739<br /> do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> ================================================================<br /> <br /> Even though fbcon_init() checks beforehand if fb_match_mode() in<br /> var_to_display() fails, it can not prevent the panic because fbcon_init()<br /> does not return error code. Considering this and the comment in the code<br /> about fb_match_mode() returning NULL - "This should not happen" - it is<br /> better to prevent registering the fb_info if its mode was not set<br /> successfully. Also move fb_add_videomode() closer to the beginning of<br /> do_register_framebuffer() to avoid having to do the cleanup on fail.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

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().