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

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tap: NULL pointer derefence in dev_parse_header_protocol when skb-&gt;dev is null<br /> <br /> Fixes a NULL pointer derefence bug triggered from tap driver.<br /> When tap_get_user calls virtio_net_hdr_to_skb the skb-&gt;dev is null<br /> (in tap.c skb-&gt;dev is set after the call to virtio_net_hdr_to_skb)<br /> virtio_net_hdr_to_skb calls dev_parse_header_protocol which<br /> needs skb-&gt;dev field to be valid.<br /> <br /> The line that trigers the bug is in dev_parse_header_protocol<br /> (dev is at offset 0x10 from skb and is stored in RAX register)<br /> if (!dev-&gt;header_ops || !dev-&gt;header_ops-&gt;parse_protocol)<br /> 22e1: mov 0x10(%rbx),%rax<br /> 22e5: mov 0x230(%rax),%rax<br /> <br /> Setting skb-&gt;dev before the call in tap.c fixes the issue.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000230<br /> RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap]<br /> Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48<br /> RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010<br /> RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300<br /> RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8<br /> R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001<br /> R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6<br /> FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0<br /> Call Trace:<br /> tap_get_user+0x3f1/0x540 [tap]<br /> tap_sendmsg+0x56/0x362 [tap]<br /> ? get_tx_bufs+0xc2/0x1e0 [vhost_net]<br /> handle_tx_copy+0x114/0x670 [vhost_net]<br /> handle_tx+0xb0/0xe0 [vhost_net]<br /> handle_tx_kick+0x15/0x20 [vhost_net]<br /> vhost_worker+0x7b/0xc0 [vhost]<br /> ? vhost_vring_call_reset+0x40/0x40 [vhost]<br /> kthread+0xfa/0x120<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x1f/0x30

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.