Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: ensure pages are unlocked on cow_file_range() failure<br /> <br /> There is a hung_task report on zoned btrfs like below.<br /> <br /> https://github.com/naota/linux/issues/59<br /> <br /> [726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds.<br /> [726.329839] Not tainted 5.16.0-rc1+ #1<br /> [726.330484] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000<br /> [726.331608] Call Trace:<br /> [726.331611] <br /> [726.331614] __schedule+0x2e5/0x9d0<br /> [726.331622] schedule+0x58/0xd0<br /> [726.331626] io_schedule+0x3f/0x70<br /> [726.331629] __folio_lock+0x125/0x200<br /> [726.331634] ? find_get_entries+0x1bc/0x240<br /> [726.331638] ? filemap_invalidate_unlock_two+0x40/0x40<br /> [726.331642] truncate_inode_pages_range+0x5b2/0x770<br /> [726.331649] truncate_inode_pages_final+0x44/0x50<br /> [726.331653] btrfs_evict_inode+0x67/0x480<br /> [726.331658] evict+0xd0/0x180<br /> [726.331661] iput+0x13f/0x200<br /> [726.331664] do_unlinkat+0x1c0/0x2b0<br /> [726.331668] __x64_sys_unlink+0x23/0x30<br /> [726.331670] do_syscall_64+0x3b/0xc0<br /> [726.331674] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [726.331677] RIP: 0033:0x7fb9490a171b<br /> [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057<br /> [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b<br /> [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300<br /> [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000<br /> [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000<br /> [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260<br /> [726.331693] <br /> <br /> While we debug the issue, we found running fstests generic/551 on 5GB<br /> non-zoned null_blk device in the emulated zoned mode also had a<br /> similar hung issue.<br /> <br /> Also, we can reproduce the same symptom with an error injected<br /> cow_file_range() setup.<br /> <br /> The hang occurs when cow_file_range() fails in the middle of<br /> allocation. cow_file_range() called from do_allocation_zoned() can<br /> split the give region ([start, end]) for allocation depending on<br /> current block group usages. When btrfs can allocate bytes for one part<br /> of the split regions but fails for the other region (e.g. because of<br /> -ENOSPC), we return the error leaving the pages in the succeeded regions<br /> locked. Technically, this occurs only when @unlock == 0. Otherwise, we<br /> unlock the pages in an allocated region after creating an ordered<br /> extent.<br /> <br /> Considering the callers of cow_file_range(unlock=0) won&amp;#39;t write out<br /> the pages, we can unlock the pages on error exit from<br /> cow_file_range(). So, we can ensure all the pages except @locked_page<br /> are unlocked on error case.<br /> <br /> In summary, cow_file_range now behaves like this:<br /> <br /> - page_started == 1 (return value)<br /> - All the pages are unlocked. IO is started.<br /> - unlock == 1<br /> - All the pages except @locked_page are unlocked in any case<br /> - unlock == 0<br /> - On success, all the pages are locked for writing out them<br /> - On failure, all the pages except @locked_page are unlocked

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)<br /> <br /> KASAN reports:<br /> <br /> [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)<br /> [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0<br /> [ 4.683454][ T0]<br /> [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1<br /> [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016<br /> [ 4.703196][ T0] Call Trace:<br /> [ 4.706334][ T0] <br /> [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)<br /> <br /> after converting the type of the first argument (@nr, bit number)<br /> of arch_test_bit() from `long` to `unsigned long`[0].<br /> <br /> Under certain conditions (for example, when ACPI NUMA is disabled<br /> via command line), pxm_to_node() can return %NUMA_NO_NODE (-1).<br /> It is valid &amp;#39;magic&amp;#39; number of NUMA node, but not valid bit number<br /> to use in bitops.<br /> node_online() eventually descends to test_bit() without checking<br /> for the input, assuming it&amp;#39;s on caller side (which might be good<br /> for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads<br /> to an insane array index when calculating bit position in memory.<br /> <br /> For now, add an explicit check for @node being not %NUMA_NO_NODE<br /> before calling test_bit(). The actual logics didn&amp;#39;t change here<br /> at all.<br /> <br /> [0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spmi: trace: fix stack-out-of-bound access in SPMI tracing functions<br /> <br /> trace_spmi_write_begin() and trace_spmi_read_end() both call<br /> memcpy() with a length of "len + 1". This leads to one extra<br /> byte being read beyond the end of the specified buffer. Fix<br /> this out-of-bound memory access by using a length of "len"<br /> instead.<br /> <br /> Here is a KASAN log showing the issue:<br /> <br /> BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234<br /> Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314<br /> ...<br /> Call trace:<br /> dump_backtrace+0x0/0x3e8<br /> show_stack+0x2c/0x3c<br /> dump_stack_lvl+0xdc/0x11c<br /> print_address_description+0x74/0x384<br /> kasan_report+0x188/0x268<br /> kasan_check_range+0x270/0x2b0<br /> memcpy+0x90/0xe8<br /> trace_event_raw_event_spmi_read_end+0x1d0/0x234<br /> spmi_read_cmd+0x294/0x3ac<br /> spmi_ext_register_readl+0x84/0x9c<br /> regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]<br /> _regmap_raw_read+0x40c/0x754<br /> regmap_raw_read+0x3a0/0x514<br /> regmap_bulk_read+0x418/0x494<br /> adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]<br /> ...<br /> __arm64_sys_read+0x4c/0x60<br /> invoke_syscall+0x80/0x218<br /> el0_svc_common+0xec/0x1c8<br /> ...<br /> <br /> addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:<br /> adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]<br /> <br /> this frame has 1 object:<br /> [32, 33) &amp;#39;status&amp;#39;<br /> <br /> Memory state around the buggy address:<br /> ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1<br /> ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00<br /> ^<br /> ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-cpu-timers: Cleanup CPU timers before freeing them during exec<br /> <br /> Commit 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a<br /> task") started looking up tasks by PID when deleting a CPU timer.<br /> <br /> When a non-leader thread calls execve, it will switch PIDs with the leader<br /> process. Then, as it calls exit_itimers, posix_cpu_timer_del cannot find<br /> the task because the timer still points out to the old PID.<br /> <br /> That means that armed timers won&amp;#39;t be disarmed, that is, they won&amp;#39;t be<br /> removed from the timerqueue_list. exit_itimers will still release their<br /> memory, and when that list is later processed, it leads to a<br /> use-after-free.<br /> <br /> Clean up the timers from the de-threaded task before freeing them. This<br /> prevents a reported use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm thin: fix use-after-free crash in dm_sm_register_threshold_callback<br /> <br /> Fault inject on pool metadata device reports:<br /> BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80<br /> Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950<br /> <br /> CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> print_address_description.constprop.0.cold+0xeb/0x3f4<br /> kasan_report.cold+0xe6/0x147<br /> dm_pool_register_metadata_threshold+0x40/0x80<br /> pool_ctr+0xa0a/0x1150<br /> dm_table_add_target+0x2c8/0x640<br /> table_load+0x1fd/0x430<br /> ctl_ioctl+0x2c4/0x5a0<br /> dm_ctl_ioctl+0xa/0x10<br /> __x64_sys_ioctl+0xb3/0xd0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> This can be easily reproduced using:<br /> echo offline &gt; /sys/block/sda/device/state<br /> dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10<br /> dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0"<br /> <br /> If a metadata commit fails, the transaction will be aborted and the<br /> metadata space maps will be destroyed. If a DM table reload then<br /> happens for this failed thin-pool, a use-after-free will occur in<br /> dm_sm_register_threshold_callback (called from<br /> dm_pool_register_metadata_threshold).<br /> <br /> Fix this by in dm_pool_register_metadata_threshold() by returning the<br /> -EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr()<br /> with a new error message: "Error registering metadata threshold".

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

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 /> mm/damon/reclaim: fix potential memory leak in damon_reclaim_init()<br /> <br /> damon_reclaim_init() allocates a memory chunk for ctx with<br /> damon_new_ctx(). When damon_select_ops() fails, ctx is not released,<br /> which will lead to a memory leak.<br /> <br /> We should release the ctx with damon_destroy_ctx() when damon_select_ops()<br /> fails to fix the memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails<br /> <br /> When scpi probe fails, at any point, we need to ensure that the scpi_info<br /> is not set and will remain NULL until the probe succeeds. If it is not<br /> taken care, then it could result use-after-free as the value is exported<br /> via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc()<br /> but freed when the probe fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: don&amp;#39;t allow the same type rq_qos add more than once<br /> <br /> In our test of iocost, we encountered some list add/del corruptions of<br /> inner_walk list in ioc_timer_fn.<br /> <br /> The reason can be described as follows:<br /> <br /> cpu 0 cpu 1<br /> ioc_qos_write ioc_qos_write<br /> <br /> ioc = q_to_ioc(queue);<br /> if (!ioc) {<br /> ioc = kzalloc();<br /> ioc = q_to_ioc(queue);<br /> if (!ioc) {<br /> ioc = kzalloc();<br /> ...<br /> rq_qos_add(q, rqos);<br /> }<br /> ...<br /> rq_qos_add(q, rqos);<br /> ...<br /> }<br /> <br /> When the io.cost.qos file is written by two cpus concurrently, rq_qos may<br /> be added to one disk twice. In that case, there will be two iocs enabled<br /> and running on one disk. They own different iocgs on their active list. In<br /> the ioc_timer_fn function, because of the iocgs from two iocs have the<br /> same root iocg, the root iocg&amp;#39;s walk_list may be overwritten by each other<br /> and this leads to list add/del corruptions in building or destroying the<br /> inner_walk list.<br /> <br /> And so far, the blk-rq-qos framework works in case that one instance for<br /> one type rq_qos per queue by default. This patch make this explicit and<br /> also fix the crash above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm raid: fix address sanitizer warning in raid_resume<br /> <br /> There is a KASAN warning in raid_resume when running the lvm test<br /> lvconvert-raid.sh. The reason for the warning is that mddev-&gt;raid_disks<br /> is greater than rs-&gt;raid_disks, so the loop touches one entry beyond<br /> the allocated length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm raid: fix address sanitizer warning in raid_status<br /> <br /> There is this warning when using a kernel with the address sanitizer<br /> and running this testsuite:<br /> https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]<br /> Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319<br /> CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3. #1<br /> Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6a/0x9c<br /> print_address_description.constprop.0+0x1f/0x1e0<br /> print_report.cold+0x55/0x244<br /> kasan_report+0xc9/0x100<br /> raid_status+0x1747/0x2820 [dm_raid]<br /> dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod]<br /> table_load+0x35c/0x630 [dm_mod]<br /> ctl_ioctl+0x411/0x630 [dm_mod]<br /> dm_ctl_ioctl+0xa/0x10 [dm_mod]<br /> __x64_sys_ioctl+0x12a/0x1a0<br /> do_syscall_64+0x5b/0x80<br /> <br /> The warning is caused by reading conf-&gt;max_nr_stripes in raid_status. The<br /> code in raid_status reads mddev-&gt;private, casts it to struct r5conf and<br /> reads the entry max_nr_stripes.<br /> <br /> However, if we have different raid type than 4/5/6, mddev-&gt;private<br /> doesn&amp;#39;t point to struct r5conf; it may point to struct r0conf, struct<br /> r1conf, struct r10conf or struct mpconf. If we cast a pointer to one<br /> of these structs to struct r5conf, we will be reading invalid memory<br /> and KASAN warns about it.<br /> <br /> Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6.