Vulnerabilities

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.

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 /> 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 /> 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 /> NFSv4/pnfs: Fix a use-after-free bug in open<br /> <br /> If someone cancels the open RPC call, then we must not try to free<br /> either the open slot or the layoutget operation arguments, since they<br /> are likely still in use by the hung RPC call.