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

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 /> apparmor: Fix memleak in aa_simple_write_to_buffer()<br /> <br /> When copy_from_user failed, the memory is freed by kvfree. however the<br /> management struct and data blob are allocated independently, so only<br /> kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to<br /> fix this issue.

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.

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 /> 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 /> 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 /> 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 /> tee: add overflow check in register_shm_helper()<br /> <br /> With special lengths supplied by user space, register_shm_helper() has<br /> an integer overflow when calculating the number of pages covered by a<br /> supplied user space memory region.<br /> <br /> This causes internal_get_user_pages_fast() a helper function of<br /> pin_user_pages_fast() to do a NULL pointer dereference:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> Modules linked in:<br /> CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015<br /> pc : internal_get_user_pages_fast+0x474/0xa80<br /> Call trace:<br /> internal_get_user_pages_fast+0x474/0xa80<br /> pin_user_pages_fast+0x24/0x4c<br /> register_shm_helper+0x194/0x330<br /> tee_shm_register_user_buf+0x78/0x120<br /> tee_ioctl+0xd0/0x11a0<br /> __arm64_sys_ioctl+0xa8/0xec<br /> invoke_syscall+0x48/0x114<br /> <br /> Fix this by adding an an explicit call to access_ok() in<br /> tee_shm_register_user_buf() to catch an invalid user space address<br /> early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: felix: suppress non-changes to the tagging protocol<br /> <br /> The way in which dsa_tree_change_tag_proto() works is that when<br /> dsa_tree_notify() fails, it doesn&amp;#39;t know whether the operation failed<br /> mid way in a multi-switch tree, or it failed for a single-switch tree.<br /> So even though drivers need to fail cleanly in<br /> ds-&gt;ops-&gt;change_tag_protocol(), DSA will still call dsa_tree_notify()<br /> again, to restore the old tag protocol for potential switches in the<br /> tree where the change did succeeed (before failing for others).<br /> <br /> This means for the felix driver that if we report an error in<br /> felix_change_tag_protocol(), we&amp;#39;ll get another call where proto_ops ==<br /> old_proto_ops. If we proceed to act upon that, we may do unexpected<br /> things. For example, we will call dsa_tag_8021q_register() twice in a<br /> row, without any dsa_tag_8021q_unregister() in between. Then we will<br /> actually call dsa_tag_8021q_unregister() via old_proto_ops-&gt;teardown,<br /> which (if it manages to run at all, after walking through corrupted data<br /> structures) will leave the ports inoperational anyway.<br /> <br /> The bug can be readily reproduced if we force an error while in<br /> tag_8021q mode; this crashes the kernel.<br /> <br /> echo ocelot-8021q &gt; /sys/class/net/eno2/dsa/tagging<br /> echo edsa &gt; /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014<br /> Call trace:<br /> vcap_entry_get+0x24/0x124<br /> ocelot_vcap_filter_del+0x198/0x270<br /> felix_tag_8021q_vlan_del+0xd4/0x21c<br /> dsa_switch_tag_8021q_vlan_del+0x168/0x2cc<br /> dsa_switch_event+0x68/0x1170<br /> dsa_tree_notify+0x14/0x34<br /> dsa_port_tag_8021q_vlan_del+0x84/0x110<br /> dsa_tag_8021q_unregister+0x15c/0x1c0<br /> felix_tag_8021q_teardown+0x16c/0x180<br /> felix_change_tag_protocol+0x1bc/0x230<br /> dsa_switch_event+0x14c/0x1170<br /> dsa_tree_change_tag_proto+0x118/0x1c0