Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic/realview: Fix refcount leak in realview_gic_of_init<br /> <br /> of_find_matching_node_and_match() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Fix handling of offline queues in blk_mq_alloc_request_hctx()<br /> <br /> This patch prevents that test nvme/004 triggers the following:<br /> <br /> UBSAN: array-index-out-of-bounds in block/blk-mq.h:135:9<br /> index 512 is out of range for type &amp;#39;long unsigned int [512]&amp;#39;<br /> Call Trace:<br /> show_stack+0x52/0x58<br /> dump_stack_lvl+0x49/0x5e<br /> dump_stack+0x10/0x12<br /> ubsan_epilogue+0x9/0x3b<br /> __ubsan_handle_out_of_bounds.cold+0x44/0x49<br /> blk_mq_alloc_request_hctx+0x304/0x310<br /> __nvme_submit_sync_cmd+0x70/0x200 [nvme_core]<br /> nvmf_connect_io_queue+0x23e/0x2a0 [nvme_fabrics]<br /> nvme_loop_connect_io_queues+0x8d/0xb0 [nvme_loop]<br /> nvme_loop_create_ctrl+0x58e/0x7d0 [nvme_loop]<br /> nvmf_create_ctrl+0x1d7/0x4d0 [nvme_fabrics]<br /> nvmf_dev_write+0xae/0x111 [nvme_fabrics]<br /> vfs_write+0x144/0x560<br /> ksys_write+0xb7/0x140<br /> __x64_sys_write+0x42/0x50<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: ftrace: consistently handle PLTs.<br /> <br /> Sometimes it is necessary to use a PLT entry to call an ftrace<br /> trampoline. This is handled by ftrace_make_call() and ftrace_make_nop(),<br /> with each having *almost* identical logic, but this is not handled by<br /> ftrace_modify_call() since its introduction in commit:<br /> <br /> 3b23e4991fb66f6d ("arm64: implement ftrace with regs")<br /> <br /> Due to this, if we ever were to call ftrace_modify_call() for a callsite<br /> which requires a PLT entry for a trampoline, then either:<br /> <br /> a) If the old addr requires a trampoline, ftrace_modify_call() will use<br /> an out-of-range address to generate the &amp;#39;old&amp;#39; branch instruction.<br /> This will result in warnings from aarch64_insn_gen_branch_imm() and<br /> ftrace_modify_code(), and no instructions will be modified. As<br /> ftrace_modify_call() will return an error, this will result in<br /> subsequent internal ftrace errors.<br /> <br /> b) If the old addr does not require a trampoline, but the new addr does,<br /> ftrace_modify_call() will use an out-of-range address to generate the<br /> &amp;#39;new&amp;#39; branch instruction. This will result in warnings from<br /> aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace<br /> the &amp;#39;old&amp;#39; branch with a BRK. This will result in a kernel panic when<br /> this BRK is later executed.<br /> <br /> Practically speaking, case (a) is vastly more likely than case (b), and<br /> typically this will result in internal ftrace errors that don&amp;#39;t<br /> necessarily affect the rest of the system. This can be demonstrated with<br /> an out-of-tree test module which triggers ftrace_modify_call(), e.g.<br /> <br /> | # insmod test_ftrace.ko<br /> | test_ftrace: Function test_function raw=0xffffb3749399201c, callsite=0xffffb37493992024<br /> | branch_imm_common: offset out of range<br /> | branch_imm_common: offset out of range<br /> | ------------[ ftrace bug ]------------<br /> | ftrace failed to modify<br /> | [] test_function+0x8/0x38 [test_ftrace]<br /> | actual: 1d:00:00:94<br /> | Updating ftrace call site to call a different ftrace function<br /> | ftrace record flags: e0000002<br /> | (2) R<br /> | expected tramp: ffffb374ae42ed54<br /> | ------------[ cut here ]------------<br /> | WARNING: CPU: 0 PID: 165 at kernel/trace/ftrace.c:2085 ftrace_bug+0x280/0x2b0<br /> | Modules linked in: test_ftrace(+)<br /> | CPU: 0 PID: 165 Comm: insmod Not tainted 5.19.0-rc2-00002-g4d9ead8b45ce #13<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : ftrace_bug+0x280/0x2b0<br /> | lr : ftrace_bug+0x280/0x2b0<br /> | sp : ffff80000839ba00<br /> | x29: ffff80000839ba00 x28: 0000000000000000 x27: ffff80000839bcf0<br /> | x26: ffffb37493994180 x25: ffffb374b0991c28 x24: ffffb374b0d70000<br /> | x23: 00000000ffffffea x22: ffffb374afcc33b0 x21: ffffb374b08f9cc8<br /> | x20: ffff572b8462c000 x19: ffffb374b08f9000 x18: ffffffffffffffff<br /> | x17: 6c6c6163202c6331 x16: ffffb374ae5ad110 x15: ffffb374b0d51ee4<br /> | x14: 0000000000000000 x13: 3435646532346561 x12: 3437336266666666<br /> | x11: 203a706d61727420 x10: 6465746365707865 x9 : ffffb374ae5149e8<br /> | x8 : 336266666666203a x7 : 706d617274206465 x6 : 00000000fffff167<br /> | x5 : ffff572bffbc4a08 x4 : 00000000fffff167 x3 : 0000000000000000<br /> | x2 : 0000000000000000 x1 : ffff572b84461e00 x0 : 0000000000000022<br /> | Call trace:<br /> | ftrace_bug+0x280/0x2b0<br /> | ftrace_replace_code+0x98/0xa0<br /> | ftrace_modify_all_code+0xe0/0x144<br /> | arch_ftrace_update_code+0x14/0x20<br /> | ftrace_startup+0xf8/0x1b0<br /> | register_ftrace_function+0x38/0x90<br /> | test_ftrace_init+0xd0/0x1000 [test_ftrace]<br /> | do_one_initcall+0x50/0x2b0<br /> | do_init_module+0x50/0x1f0<br /> | load_module+0x17c8/0x1d64<br /> | __do_sys_finit_module+0xa8/0x100<br /> | __arm64_sys_finit_module+0x2c/0x3c<br /> | invoke_syscall+0x50/0x120<br /> | el0_svc_common.constprop.0+0xdc/0x100<br /> | do_el0_svc+0x3c/0xd0<br /> | el0_svc+0x34/0xb0<br /> | el0t_64_sync_handler+0xbc/0x140<br /> | el0t_64_sync+0x18c/0x190<br /> | ---[ end trace 0000000000000000 ]---<br /> <br /> We can solve this by consistently determining whether to use a PLT entry<br /> for an address.<br /> <br /> Note that since (the earlier) commit:<br /> <br /> f1a54ae9<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix memory corruption in VF driver<br /> <br /> Disable VF&amp;#39;s RX/TX queues, when it&amp;#39;s disabled. VF can have queues enabled,<br /> when it requests a reset. If PF driver assumes that VF is disabled,<br /> while VF still has queues configured, VF may unmap DMA resources.<br /> In such scenario device still can map packets to memory, which ends up<br /> silently corrupting it.<br /> Previously, VF driver could experience memory corruption, which lead to<br /> crash:<br /> [ 5119.170157] BUG: unable to handle kernel paging request at 00001b9780003237<br /> [ 5119.170166] PGD 0 P4D 0<br /> [ 5119.170173] Oops: 0002 [#1] PREEMPT_RT SMP PTI<br /> [ 5119.170181] CPU: 30 PID: 427592 Comm: kworker/u96:2 Kdump: loaded Tainted: G W I --------- - - 4.18.0-372.9.1.rt7.166.el8.x86_64 #1<br /> [ 5119.170189] Hardware name: Dell Inc. PowerEdge R740/014X06, BIOS 2.3.10 08/15/2019<br /> [ 5119.170193] Workqueue: iavf iavf_adminq_task [iavf]<br /> [ 5119.170219] RIP: 0010:__page_frag_cache_drain+0x5/0x30<br /> [ 5119.170238] Code: 0f 0f b6 77 51 85 f6 74 07 31 d2 e9 05 df ff ff e9 90 fe ff ff 48 8b 05 49 db 33 01 eb b4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 29 77 34 74 01 c3 48 8b 07 f6 c4 80 74 0f 0f b6 77 51 85 f6 74<br /> [ 5119.170244] RSP: 0018:ffffa43b0bdcfd78 EFLAGS: 00010282<br /> [ 5119.170250] RAX: ffffffff896b3e40 RBX: ffff8fb282524000 RCX: 0000000000000002<br /> [ 5119.170254] RDX: 0000000049000000 RSI: 0000000000000000 RDI: 00001b9780003203<br /> [ 5119.170259] RBP: ffff8fb248217b00 R08: 0000000000000022 R09: 0000000000000009<br /> [ 5119.170262] R10: 2b849d6300000000 R11: 0000000000000020 R12: 0000000000000000<br /> [ 5119.170265] R13: 0000000000001000 R14: 0000000000000009 R15: 0000000000000000<br /> [ 5119.170269] FS: 0000000000000000(0000) GS:ffff8fb1201c0000(0000) knlGS:0000000000000000<br /> [ 5119.170274] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 5119.170279] CR2: 00001b9780003237 CR3: 00000008f3e1a003 CR4: 00000000007726e0<br /> [ 5119.170283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 5119.170286] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 5119.170290] PKRU: 55555554<br /> [ 5119.170292] Call Trace:<br /> [ 5119.170298] iavf_clean_rx_ring+0xad/0x110 [iavf]<br /> [ 5119.170324] iavf_free_rx_resources+0xe/0x50 [iavf]<br /> [ 5119.170342] iavf_free_all_rx_resources.part.51+0x30/0x40 [iavf]<br /> [ 5119.170358] iavf_virtchnl_completion+0xd8a/0x15b0 [iavf]<br /> [ 5119.170377] ? iavf_clean_arq_element+0x210/0x280 [iavf]<br /> [ 5119.170397] iavf_adminq_task+0x126/0x2e0 [iavf]<br /> [ 5119.170416] process_one_work+0x18f/0x420<br /> [ 5119.170429] worker_thread+0x30/0x370<br /> [ 5119.170437] ? process_one_work+0x420/0x420<br /> [ 5119.170445] kthread+0x151/0x170<br /> [ 5119.170452] ? set_kthread_struct+0x40/0x40<br /> [ 5119.170460] ret_from_fork+0x35/0x40<br /> [ 5119.170477] Modules linked in: iavf sctp ip6_udp_tunnel udp_tunnel mlx4_en mlx4_core nfp tls vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM ipt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache sunrpc intel_rapl_msr iTCO_wdt iTCO_vendor_support dell_smbios wmi_bmof dell_wmi_descriptor dcdbas kvm_intel kvm irqbypass intel_rapl_common isst_if_common skx_edac irdma nfit libnvdimm x86_pkg_temp_thermal i40e intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ib_uverbs rapl ipmi_ssif intel_cstate intel_uncore mei_me pcspkr acpi_ipmi ib_core mei lpc_ich i2c_i801 ipmi_si ipmi_devintf wmi ipmi_msghandler acpi_power_meter xfs libcrc32c sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ice ahci drm libahci crc32c_intel libata tg3 megaraid_sas<br /> [ 5119.170613] i2c_algo_bit dm_mirror dm_region_hash dm_log dm_mod fuse [last unloaded: iavf]<br /> [ 5119.170627] CR2: 00001b9780003237

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/reset: Fix error_state_read ptr + offset use<br /> <br /> Fix our pointer offset usage in error_state_read<br /> when there is no i915_gpu_coredump but buf offset<br /> is non-zero.<br /> <br /> This fixes a kernel page fault can happen when<br /> multiple tests are running concurrently in a loop<br /> and one is producing engine resets and consuming<br /> the i915 error_state dump while the other is<br /> forcing full GT resets. (takes a while to trigger).<br /> <br /> The dmesg call trace:<br /> <br /> [ 5590.803000] BUG: unable to handle page fault for address:<br /> ffffffffa0b0e000<br /> [ 5590.803009] #PF: supervisor read access in kernel mode<br /> [ 5590.803013] #PF: error_code(0x0000) - not-present page<br /> [ 5590.803016] PGD 5814067 P4D 5814067 PUD 5815063 PMD 109de4067<br /> PTE 0<br /> [ 5590.803022] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 5590.803026] CPU: 5 PID: 13656 Comm: i915_hangman Tainted: G U<br /> 5.17.0-rc5-ups69-guc-err-capt-rev6+ #136<br /> [ 5590.803033] Hardware name: Intel Corporation Alder Lake Client<br /> Platform/AlderLake-M LP4x RVP, BIOS ADLPFWI1.R00.<br /> 3031.A02.2201171222 01/17/2022<br /> [ 5590.803039] RIP: 0010:memcpy_erms+0x6/0x10<br /> [ 5590.803045] Code: fe ff ff cc eb 1e 0f 1f 00 48 89 f8 48 89 d1<br /> 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3<br /> 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4<br /> c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20<br /> 72 7e 40 38 fe<br /> [ 5590.803054] RSP: 0018:ffffc90003a8fdf0 EFLAGS: 00010282<br /> [ 5590.803057] RAX: ffff888107ee9000 RBX: ffff888108cb1a00<br /> RCX: 0000000000000f8f<br /> [ 5590.803061] RDX: 0000000000001000 RSI: ffffffffa0b0e000<br /> RDI: ffff888107ee9071<br /> [ 5590.803065] RBP: 0000000000000000 R08: 0000000000000001<br /> R09: 0000000000000001<br /> [ 5590.803069] R10: 0000000000000001 R11: 0000000000000002<br /> R12: 0000000000000019<br /> [ 5590.803073] R13: 0000000000174fff R14: 0000000000001000<br /> R15: ffff888107ee9000<br /> [ 5590.803077] FS: 00007f62a99bee80(0000) GS:ffff88849f880000(0000)<br /> knlGS:0000000000000000<br /> [ 5590.803082] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 5590.803085] CR2: ffffffffa0b0e000 CR3: 000000010a1a8004<br /> CR4: 0000000000770ee0<br /> [ 5590.803089] PKRU: 55555554<br /> [ 5590.803091] Call Trace:<br /> [ 5590.803093] <br /> [ 5590.803096] error_state_read+0xa1/0xd0 [i915]<br /> [ 5590.803175] kernfs_fop_read_iter+0xb2/0x1b0<br /> [ 5590.803180] new_sync_read+0x116/0x1a0<br /> [ 5590.803185] vfs_read+0x114/0x1b0<br /> [ 5590.803189] ksys_read+0x63/0xe0<br /> [ 5590.803193] do_syscall_64+0x38/0xc0<br /> [ 5590.803197] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 5590.803201] RIP: 0033:0x7f62aaea5912<br /> [ 5590.803204] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 5a b9 0c 00 e8 05<br /> 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25<br /> 18 00 00 00 85 c0 75 10 0f 05 3d 00 f0 ff<br /> ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24<br /> [ 5590.803213] RSP: 002b:00007fff5b659ae8 EFLAGS: 00000246<br /> ORIG_RAX: 0000000000000000<br /> [ 5590.803218] RAX: ffffffffffffffda RBX: 0000000000100000<br /> RCX: 00007f62aaea5912<br /> [ 5590.803221] RDX: 000000000008b000 RSI: 00007f62a8c4000f<br /> RDI: 0000000000000006<br /> [ 5590.803225] RBP: 00007f62a8bcb00f R08: 0000000000200010<br /> R09: 0000000000101000<br /> [ 5590.803229] R10: 0000000000000001 R11: 0000000000000246<br /> R12: 0000000000000006<br /> [ 5590.803233] R13: 0000000000075000 R14: 00007f62a8acb010<br /> R15: 0000000000200000<br /> [ 5590.803238] <br /> [ 5590.803240] Modules linked in: i915 ttm drm_buddy drm_dp_helper<br /> drm_kms_helper syscopyarea sysfillrect sysimgblt<br /> fb_sys_fops prime_numbers nfnetlink br_netfilter<br /> overlay mei_pxp mei_hdcp x86_pkg_temp_thermal<br /> coretemp kvm_intel snd_hda_codec_hdmi snd_hda_intel<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p: fix fid refcount leak in v9fs_vfs_get_link<br /> <br /> we check for protocol version later than required, after a fid has<br /> been obtained. Just move the version check earlier.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl<br /> <br /> We need to release directory fid if we fail halfway through open<br /> <br /> This fixes fid leaking with xfstests generic 531

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zonefs: fix zonefs_iomap_begin() for reads<br /> <br /> If a readahead is issued to a sequential zone file with an offset<br /> exactly equal to the current file size, the iomap type is set to<br /> IOMAP_UNWRITTEN, which will prevent an IO, but the iomap length is<br /> calculated as 0. This causes a WARN_ON() in iomap_iter():<br /> <br /> [17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80<br /> [...]<br /> [17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80<br /> [...]<br /> [17309.754560] Call Trace:<br /> [17309.757078] <br /> [17309.759240] ? lock_is_held_type+0xd8/0x130<br /> [17309.763531] iomap_readahead+0x1a8/0x870<br /> [17309.767550] ? iomap_read_folio+0x4c0/0x4c0<br /> [17309.771817] ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> [17309.778848] ? lock_release+0x370/0x750<br /> [17309.784462] ? folio_add_lru+0x217/0x3f0<br /> [17309.790220] ? reacquire_held_locks+0x4e0/0x4e0<br /> [17309.796543] read_pages+0x17d/0xb60<br /> [17309.801854] ? folio_add_lru+0x238/0x3f0<br /> [17309.807573] ? readahead_expand+0x5f0/0x5f0<br /> [17309.813554] ? policy_node+0xb5/0x140<br /> [17309.819018] page_cache_ra_unbounded+0x27d/0x450<br /> [17309.825439] filemap_get_pages+0x500/0x1450<br /> [17309.831444] ? filemap_add_folio+0x140/0x140<br /> [17309.837519] ? lock_is_held_type+0xd8/0x130<br /> [17309.843509] filemap_read+0x28c/0x9f0<br /> [17309.848953] ? zonefs_file_read_iter+0x1ea/0x4d0 [zonefs]<br /> [17309.856162] ? trace_contention_end+0xd6/0x130<br /> [17309.862416] ? __mutex_lock+0x221/0x1480<br /> [17309.868151] ? zonefs_file_read_iter+0x166/0x4d0 [zonefs]<br /> [17309.875364] ? filemap_get_pages+0x1450/0x1450<br /> [17309.881647] ? __mutex_unlock_slowpath+0x15e/0x620<br /> [17309.888248] ? wait_for_completion_io_timeout+0x20/0x20<br /> [17309.895231] ? lock_is_held_type+0xd8/0x130<br /> [17309.901115] ? lock_is_held_type+0xd8/0x130<br /> [17309.906934] zonefs_file_read_iter+0x356/0x4d0 [zonefs]<br /> [17309.913750] new_sync_read+0x2d8/0x520<br /> [17309.919035] ? __x64_sys_lseek+0x1d0/0x1d0<br /> <br /> Furthermore, this causes iomap_readahead() to loop forever as<br /> iomap_readahead_iter() always returns 0, making no progress.<br /> <br /> Fix this by treating reads after the file size as access to holes,<br /> setting the iomap type to IOMAP_HOLE, the iomap addr to IOMAP_NULL_ADDR<br /> and using the length argument as is for the iomap length. To simplify<br /> the code with this change, zonefs_iomap_begin() is split into the read<br /> variant, zonefs_read_iomap_begin() and zonefs_read_iomap_ops, and the<br /> write variant, zonefs_write_iomap_begin() and zonefs_write_iomap_ops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: add reserved GDT blocks check<br /> <br /> We capture a NULL pointer issue when resizing a corrupt ext4 image which<br /> is freshly clear resize_inode feature (not run e2fsck). It could be<br /> simply reproduced by following steps. The problem is because of the<br /> resize_inode feature was cleared, and it will convert the filesystem to<br /> meta_bg mode in ext4_resize_fs(), but the es-&gt;s_reserved_gdt_blocks was<br /> not reduced to zero, so could we mistakenly call reserve_backup_gdb()<br /> and passing an uninitialized resize_inode to it when adding new group<br /> descriptors.<br /> <br /> mkfs.ext4 /dev/sda 3G<br /> tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck<br /> mount /dev/sda /mnt<br /> resize2fs /dev/sda 8G<br /> <br /> ========<br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748<br /> ...<br /> RIP: 0010:ext4_flex_group_add+0xe08/0x2570<br /> ...<br /> Call Trace:<br /> <br /> ext4_resize_fs+0xbec/0x1660<br /> __ext4_ioctl+0x1749/0x24e0<br /> ext4_ioctl+0x12/0x20<br /> __x64_sys_ioctl+0xa6/0x110<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f2dd739617b<br /> ========<br /> <br /> The fix is simple, add a check in ext4_resize_begin() to make sure that<br /> the es-&gt;s_reserved_gdt_blocks is zero when the resize_inode feature is<br /> disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug_on ext4_mb_use_inode_pa<br /> <br /> Hulk Robot reported a BUG_ON:<br /> ==================================================================<br /> kernel BUG at fs/ext4/mballoc.c:3211!<br /> [...]<br /> RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f<br /> [...]<br /> Call Trace:<br /> ext4_mb_new_blocks+0x9df/0x5d30<br /> ext4_ext_map_blocks+0x1803/0x4d80<br /> ext4_map_blocks+0x3a4/0x1a10<br /> ext4_writepages+0x126d/0x2c30<br /> do_writepages+0x7f/0x1b0<br /> __filemap_fdatawrite_range+0x285/0x3b0<br /> file_write_and_wait_range+0xb1/0x140<br /> ext4_sync_file+0x1aa/0xca0<br /> vfs_fsync_range+0xfb/0x260<br /> do_fsync+0x48/0xa0<br /> [...]<br /> ==================================================================<br /> <br /> Above issue may happen as follows:<br /> -------------------------------------<br /> do_fsync<br /> vfs_fsync_range<br /> ext4_sync_file<br /> file_write_and_wait_range<br /> __filemap_fdatawrite_range<br /> do_writepages<br /> ext4_writepages<br /> mpage_map_and_submit_extent<br /> mpage_map_one_extent<br /> ext4_map_blocks<br /> ext4_mb_new_blocks<br /> ext4_mb_normalize_request<br /> &gt;&gt;&gt; start + size ac_o_ex.fe_logical<br /> ext4_mb_regular_allocator<br /> ext4_mb_simple_scan_group<br /> ext4_mb_use_best_found<br /> ext4_mb_new_preallocation<br /> ext4_mb_new_inode_pa<br /> ext4_mb_use_inode_pa<br /> &gt;&gt;&gt; set ac-&gt;ac_b_ex.fe_len &gt;&gt; BUG_ON(ac-&gt;ac_b_ex.fe_len

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cfi: Fix __cfi_slowpath_diag RCU usage with cpuidle<br /> <br /> RCU_NONIDLE usage during __cfi_slowpath_diag can result in an invalid<br /> RCU state in the cpuidle code path:<br /> <br /> WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:613 rcu_eqs_enter+0xe4/0x138<br /> ...<br /> Call trace:<br /> rcu_eqs_enter+0xe4/0x138<br /> rcu_idle_enter+0xa8/0x100<br /> cpuidle_enter_state+0x154/0x3a8<br /> cpuidle_enter+0x3c/0x58<br /> do_idle.llvm.6590768638138871020+0x1f4/0x2ec<br /> cpu_startup_entry+0x28/0x2c<br /> secondary_start_kernel+0x1b8/0x220<br /> __secondary_switched+0x94/0x98<br /> <br /> Instead, call rcu_irq_enter/exit to wake up RCU only when needed and<br /> disable interrupts for the entire CFI shadow/module check when we do.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm mirror log: round up region bitmap size to BITS_PER_LONG<br /> <br /> The code in dm-log rounds up bitset_size to 32 bits. It then uses<br /> find_next_zero_bit_le on the allocated region. find_next_zero_bit_le<br /> accesses the bitmap using unsigned long pointers. So, on 64-bit<br /> architectures, it may access 4 bytes beyond the allocated size.<br /> <br /> Fix this bug by rounding up bitset_size to BITS_PER_LONG.<br /> <br /> This bug was found by running the lvm2 testsuite with kasan.