Vulnerabilities

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

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.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc: fix to protect IPCS lookups using RCU<br /> <br /> syzbot reported that it discovered a use-after-free vulnerability, [0]<br /> <br /> [0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/<br /> <br /> idr_for_each() is protected by rwsem, but this is not enough. If it is<br /> not protected by RCU read-critical region, when idr_for_each() calls<br /> radix_tree_node_free() through call_rcu() to free the radix_tree_node<br /> structure, the node will be freed immediately, and when reading the next<br /> node in radix_tree_for_each_slot(), the already freed memory may be read.<br /> <br /> Therefore, we need to add code to make sure that idr_for_each() is<br /> protected within the RCU read-critical region when we call it in<br /> shm_destroy_orphaned().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vgacon: Add check for vc_origin address range in vgacon_scroll()<br /> <br /> Our in-house Syzkaller reported the following BUG (twice), which we<br /> believed was the same issue with [1]:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740<br /> Read of size 2 at addr ffff88800f5bef60 by task syz.7.2620/12393<br /> ...<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106<br /> print_address_description.constprop.0+0x6b/0x3d0 mm/kasan/report.c:364<br /> print_report+0xba/0x280 mm/kasan/report.c:475<br /> kasan_report+0xa9/0xe0 mm/kasan/report.c:588<br /> vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740<br /> vcs_write_buf_noattr drivers/tty/vt/vc_screen.c:493 [inline]<br /> vcs_write+0x586/0x840 drivers/tty/vt/vc_screen.c:690<br /> vfs_write+0x219/0x960 fs/read_write.c:584<br /> ksys_write+0x12e/0x260 fs/read_write.c:639<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> ...<br /> <br /> <br /> Allocated by task 5614:<br /> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> ____kasan_kmalloc mm/kasan/common.c:374 [inline]<br /> __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:383<br /> kasan_kmalloc include/linux/kasan.h:201 [inline]<br /> __do_kmalloc_node mm/slab_common.c:1007 [inline]<br /> __kmalloc+0x62/0x140 mm/slab_common.c:1020<br /> kmalloc include/linux/slab.h:604 [inline]<br /> kzalloc include/linux/slab.h:721 [inline]<br /> vc_do_resize+0x235/0xf40 drivers/tty/vt/vt.c:1193<br /> vgacon_adjust_height+0x2d4/0x350 drivers/video/console/vgacon.c:1007<br /> vgacon_font_set+0x1f7/0x240 drivers/video/console/vgacon.c:1031<br /> con_font_set drivers/tty/vt/vt.c:4628 [inline]<br /> con_font_op+0x4da/0xa20 drivers/tty/vt/vt.c:4675<br /> vt_k_ioctl+0xa10/0xb30 drivers/tty/vt/vt_ioctl.c:474<br /> vt_ioctl+0x14c/0x1870 drivers/tty/vt/vt_ioctl.c:752<br /> tty_ioctl+0x655/0x1510 drivers/tty/tty_io.c:2779<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:871 [inline]<br /> __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45<br /> __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492<br /> __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713<br /> netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802<br /> __sock_release+0xb5/0x270 net/socket.c:663<br /> sock_close+0x1e/0x30 net/socket.c:1425<br /> __fput+0x408/0xab0 fs/file_table.c:384<br /> __fput_sync+0x4c/0x60 fs/file_table.c:465<br /> __do_sys_close fs/open.c:1580 [inline]<br /> __se_sys_close+0x68/0xd0 fs/open.c:1565<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> Second to last potentially related work creation:<br /> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45<br /> __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492<br /> __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713<br /> netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802<br /> __sock_release+0xb5/0x270 net/socket.c:663<br /> sock_close+0x1e/0x30 net/socket.c:1425<br /> __fput+0x408/0xab0 fs/file_table.c:384<br /> task_work_run+0x154/0x240 kernel/task_work.c:239<br /> exit_task_work include/linux/task_work.h:45 [inline]<br /> do_exit+0x8e5/0x1320 kernel/exit.c:874<br /> do_group_exit+0xcd/0x280 kernel/exit.c:1023<br /> get_signal+0x1675/0x1850 kernel/signal.c:2905<br /> arch_do_signal_or_restart+0x80/0x3b0 arch/x86/kernel/signal.c:310<br /> exit_to_user_mode_loop kernel/entry/common.c:111 [inline]<br /> exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]<br /> syscall_exit_to_user_mode+0x1b3/0x1e0 kernel/entry/common.c:218<br /> do_syscall_64+0x66/0x110 arch/x86/ent<br /> ---truncated---

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 /> netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX<br /> <br /> Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()<br /> when resizing hashtable because __GFP_NOWARN is unset.<br /> <br /> Similar to:<br /> <br /> b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()<br /> <br /> bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf<br /> program. When BPF JIT is disabled or under 32-bit host,<br /> bpf_map_lookup_percpu_elem() will not be inlined. Using it in a<br /> sleepable bpf program will trigger the warning in<br /> bpf_map_lookup_percpu_elem(), because the bpf program only holds<br /> rcu_read_lock_trace lock. Therefore, add the missed check.