Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check correct bounds for stream encoder instances for DCN303<br /> <br /> [Why &amp; How]<br /> eng_id for DCN303 cannot be more than 1, since we have only two<br /> instances of stream encoders.<br /> <br /> Check the correct boundary condition for engine ID for DCN303 prevent<br /> the potential out of bounds access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/eprobes: Do not allow eprobes to use $stack, or % for regs<br /> <br /> While playing with event probes (eprobes), I tried to see what would<br /> happen if I attempted to retrieve the instruction pointer (%rip) knowing<br /> that event probes do not use pt_regs. The result was:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000024<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 1847 Comm: trace-cmd Not tainted 5.19.0-rc5-test+ #309<br /> Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01<br /> v03.03 07/14/2016<br /> RIP: 0010:get_event_field.isra.0+0x0/0x50<br /> Code: ff 48 c7 c7 c0 8f 74 a1 e8 3d 8b f5 ff e8 88 09 f6 ff 4c 89 e7 e8<br /> 50 6a 13 00 48 89 ef 5b 5d 41 5c 41 5d e9 42 6a 13 00 66 90 63 47 24<br /> 8b 57 2c 48 01 c6 8b 47 28 83 f8 02 74 0e 83 f8 04 74<br /> RSP: 0018:ffff916c394bbaf0 EFLAGS: 00010086<br /> RAX: ffff916c854041d8 RBX: ffff916c8d9fbf50 RCX: ffff916c255d2000<br /> RDX: 0000000000000000 RSI: ffff916c255d2008 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: ffff916c3a2a0c08 R09: ffff916c394bbda8<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff916c854041d8<br /> R13: ffff916c854041b0 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff916c9ea40000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000024 CR3: 000000011b60a002 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> get_eprobe_size+0xb4/0x640<br /> ? __mod_node_page_state+0x72/0xc0<br /> __eprobe_trace_func+0x59/0x1a0<br /> ? __mod_lruvec_page_state+0xaa/0x1b0<br /> ? page_remove_file_rmap+0x14/0x230<br /> ? page_remove_rmap+0xda/0x170<br /> event_triggers_call+0x52/0xe0<br /> trace_event_buffer_commit+0x18f/0x240<br /> trace_event_raw_event_sched_wakeup_template+0x7a/0xb0<br /> try_to_wake_up+0x260/0x4c0<br /> __wake_up_common+0x80/0x180<br /> __wake_up_common_lock+0x7c/0xc0<br /> do_notify_parent+0x1c9/0x2a0<br /> exit_notify+0x1a9/0x220<br /> do_exit+0x2ba/0x450<br /> do_group_exit+0x2d/0x90<br /> __x64_sys_exit_group+0x14/0x20<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Obviously this is not the desired result.<br /> <br /> Move the testing for TPARG_FL_TPOINT which is only used for event probes<br /> to the top of the "$" variable check, as all the other variables are not<br /> used for event probes. Also add a check in the register parsing "%" to<br /> fail if an event probe is used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix reference count leak in aa_pivotroot()<br /> <br /> The aa_pivotroot() function has a reference counting bug in a specific<br /> path. When aa_replace_current_label() returns on success, the function<br /> forgets to decrement the reference count of “target”, which is<br /> increased earlier by build_pivotroot(), causing a reference leak.<br /> <br /> Fix it by decreasing the refcount of “target” in that path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix memory leak on the deferred close<br /> <br /> xfstests on smb21 report kmemleak as below:<br /> <br /> unreferenced object 0xffff8881767d6200 (size 64):<br /> comm "xfs_io", pid 1284, jiffies 4294777434 (age 20.789s)<br /> hex dump (first 32 bytes):<br /> 80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff .Z......x..c....<br /> 00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00 .q.v............<br /> backtrace:<br /> [] cifs_close+0x92/0x2c0<br /> [] __fput+0xff/0x3f0<br /> [] task_work_run+0x85/0xc0<br /> [] do_exit+0x5e5/0x1240<br /> [] do_group_exit+0x58/0xe0<br /> [] __x64_sys_exit_group+0x28/0x30<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> When cancel the deferred close work, we should also cleanup the struct<br /> cifs_deferred_close.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/eprobes: Have event probes be consistent with kprobes and uprobes<br /> <br /> Currently, if a symbol "@" is attempted to be used with an event probe<br /> (eprobes), it will cause a NULL pointer dereference crash.<br /> <br /> Both kprobes and uprobes can reference data other than the main registers.<br /> Such as immediate address, symbols and the current task name. Have eprobes<br /> do the same thing.<br /> <br /> For "comm", if "comm" is used and the event being attached to does not<br /> have the "comm" field, then make it the "$comm" that kprobes has. This is<br /> consistent to the way histograms and filters work.