Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/csd_lock: Change csdlock_debug from early_param to __setup<br /> <br /> The csdlock_debug kernel-boot parameter is parsed by the<br /> early_param() function csdlock_debug(). If set, csdlock_debug()<br /> invokes static_branch_enable() to enable csd_lock_wait feature, which<br /> triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and<br /> CONFIG_SPARSEMEM_VMEMMAP=n.<br /> <br /> With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in<br /> static_key_enable() and returns NULL, resulting in a NULL dereference<br /> because mem_section is initialized only later in sparse_init().<br /> <br /> This is also a problem for powerpc because early_param() functions<br /> are invoked earlier than jump_label_init(), also resulting in<br /> static_key_enable() failures. These failures cause the warning "static<br /> key &amp;#39;xxx&amp;#39; used before call to jump_label_init()".<br /> <br /> Thus, early_param is too early for csd_lock_wait to run<br /> static_branch_enable(), so changes it to __setup to fix these.

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

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 /> x86/kprobes: Update kcb status flag after singlestepping<br /> <br /> Fix kprobes to update kcb (kprobes control block) status flag to<br /> KPROBE_HIT_SSDONE even if the kp-&gt;post_handler is not set.<br /> <br /> This bug may cause a kernel panic if another INT3 user runs right<br /> after kprobes because kprobe_int3_handler() misunderstands the<br /> INT3 is kprobe&amp;#39;s single stepping INT3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: s3fb: Check the size of screen before memset_io()<br /> <br /> In the function s3fb_set_par(), the value of &amp;#39;screen_size&amp;#39; is<br /> calculated by the user input. If the user provides the improper value,<br /> the value of &amp;#39;screen_size&amp;#39; may larger than &amp;#39;info-&gt;screen_size&amp;#39;, which<br /> may cause the following bug:<br /> <br /> [ 54.083733] BUG: unable to handle page fault for address: ffffc90003000000<br /> [ 54.083742] #PF: supervisor write access in kernel mode<br /> [ 54.083744] #PF: error_code(0x0002) - not-present page<br /> [ 54.083760] RIP: 0010:memset_orig+0x33/0xb0<br /> [ 54.083782] Call Trace:<br /> [ 54.083788] s3fb_set_par+0x1ec6/0x4040<br /> [ 54.083806] fb_set_var+0x604/0xeb0<br /> [ 54.083836] do_fb_ioctl+0x234/0x670<br /> <br /> Fix the this by checking the value of &amp;#39;screen_size&amp;#39; before memset_io().

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 /> ext4: fix warning in ext4_iomap_begin as race between bmap and write<br /> <br /> We got issue as follows:<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0<br /> RIP: 0010:ext4_iomap_begin+0x182/0x5d0<br /> RSP: 0018:ffff88812460fa08 EFLAGS: 00010293<br /> RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f<br /> R10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001<br /> R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee<br /> FS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> iomap_apply+0x119/0x570<br /> iomap_bmap+0x124/0x150<br /> ext4_bmap+0x14f/0x250<br /> bmap+0x55/0x80<br /> do_vfs_ioctl+0x952/0xbd0<br /> __x64_sys_ioctl+0xc6/0x170<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Above issue may happen as follows:<br /> bmap write<br /> bmap<br /> ext4_bmap<br /> iomap_bmap<br /> ext4_iomap_begin<br /> ext4_file_write_iter<br /> ext4_buffered_write_iter<br /> generic_perform_write<br /> ext4_da_write_begin<br /> ext4_da_write_inline_data_begin<br /> ext4_prepare_inline_data<br /> ext4_create_inline_data<br /> ext4_set_inode_flag(inode,<br /> EXT4_INODE_INLINE_DATA);<br /> if (WARN_ON_ONCE(ext4_has_inline_data(inode))) -&gt;trigger bug_on<br /> <br /> To solved above issue hold inode lock in ext4_bamp.

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

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.