Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Fix use after free in remove_phb_dynamic()<br /> <br /> In remove_phb_dynamic() we use &amp;phb-&gt;io_resource, after we&amp;#39;ve called<br /> device_unregister(&amp;host_bridge-&gt;dev). But the unregister may have freed<br /> phb, because pcibios_free_controller_deferred() is the release function<br /> for the host_bridge.<br /> <br /> If there are no outstanding references when we call device_unregister()<br /> then phb will be freed out from under us.<br /> <br /> This has gone mainly unnoticed, but with slub_debug and page_poison<br /> enabled it can lead to a crash:<br /> <br /> PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr"<br /> #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc<br /> #1 [c0000000e4f075d0] oops_end at c000000000029608<br /> #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4<br /> #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8<br /> #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30<br /> Data SLB Access [380] exception frame:<br /> R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100<br /> R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9<br /> R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff<br /> R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000<br /> R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000<br /> R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003<br /> R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005<br /> R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0<br /> R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8<br /> R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800<br /> R30: c00000004d1d2400 R31: c00000004d1d2540<br /> NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474<br /> CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003<br /> CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3<br /> DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2<br /> [NIP : release_resource+56]<br /> [LR : release_resource+48]<br /> #5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable)<br /> #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648<br /> #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io]<br /> #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io]<br /> #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c<br /> #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504<br /> #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868<br /> #12 [c0000000e4f07c70] new_sync_write at c00000000054339c<br /> #13 [c0000000e4f07d10] vfs_write at c000000000546624<br /> #14 [c0000000e4f07d60] ksys_write at c0000000005469f4<br /> #15 [c0000000e4f07db0] system_call_exception at c000000000030840<br /> #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168<br /> <br /> To avoid it, we can take a reference to the host_bridge-&gt;dev until we&amp;#39;re<br /> done using phb. Then when we drop the reference the phb will be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_netlink: Fix shift out of bounds in group mask calculation<br /> <br /> When a netlink message is received, netlink_recvmsg() fills in the address<br /> of the sender. One of the fields is the 32-bit bitfield nl_groups, which<br /> carries the multicast group on which the message was received. The least<br /> significant bit corresponds to group 1, and therefore the highest group<br /> that the field can represent is 32. Above that, the UB sanitizer flags the<br /> out-of-bounds shift attempts.<br /> <br /> Which bits end up being set in such case is implementation defined, but<br /> it&amp;#39;s either going to be a wrong non-zero value, or zero, which is at least<br /> not misleading. Make the latter choice deterministic by always setting to 0<br /> for higher-numbered multicast groups.<br /> <br /> To get information about membership in groups &gt;= 32, userspace is expected<br /> to use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFO<br /> socket option.<br /> [0] https://lwn.net/Articles/147608/<br /> <br /> The way to trigger this issue is e.g. through monitoring the BRVLAN group:<br /> <br /> # bridge monitor vlan &amp;<br /> # ip link add name br type bridge<br /> <br /> Which produces the following citation:<br /> <br /> UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19<br /> shift exponent 32 is too large for 32-bit type &amp;#39;int&amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: Fix crash due to tcp_tsorted_anchor was initialized before release skb<br /> <br /> Got crash when doing pressure test of mptcp:<br /> <br /> ===========================================================================<br /> dst_release: dst:ffffa06ce6e5c058 refcnt:-1<br /> kernel tried to execute NX-protected page - exploit attempt? (uid: 0)<br /> BUG: unable to handle kernel paging request at ffffa06ce6e5c058<br /> PGD 190a01067 P4D 190a01067 PUD 43fffb067 PMD 22e403063 PTE 8000000226e5c063<br /> Oops: 0011 [#1] SMP PTI<br /> CPU: 7 PID: 7823 Comm: kworker/7:0 Kdump: loaded Tainted: G E<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.2.1 04/01/2014<br /> Call Trace:<br /> ? skb_release_head_state+0x68/0x100<br /> ? skb_release_all+0xe/0x30<br /> ? kfree_skb+0x32/0xa0<br /> ? mptcp_sendmsg_frag+0x57e/0x750<br /> ? __mptcp_retrans+0x21b/0x3c0<br /> ? __switch_to_asm+0x35/0x70<br /> ? mptcp_worker+0x25e/0x320<br /> ? process_one_work+0x1a7/0x360<br /> ? worker_thread+0x30/0x390<br /> ? create_worker+0x1a0/0x1a0<br /> ? kthread+0x112/0x130<br /> ? kthread_flush_work_fn+0x10/0x10<br /> ? ret_from_fork+0x35/0x40<br /> ===========================================================================<br /> <br /> In __mptcp_alloc_tx_skb skb was allocated and skb-&gt;tcp_tsorted_anchor will<br /> be initialized, in under memory pressure situation sk_wmem_schedule will<br /> return false and then kfree_skb. In this case skb-&gt;_skb_refdst is not null<br /> because_skb_refdst and tcp_tsorted_anchor are stored in the same mem, and<br /> kfree_skb will try to release dst and cause crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/nldev: Prevent underflow in nldev_stat_set_counter_dynamic_doit()<br /> <br /> This code checks "index" for an upper bound but it does not check for<br /> negatives. Change the type to unsigned to prevent underflows.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernel/resource: fix kfree() of bootmem memory again<br /> <br /> Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem<br /> memory"), we could get a resource allocated during boot via<br /> alloc_resource(). And it&amp;#39;s required to release the resource using<br /> free_resource(). Howerver, many people use kfree directly which will<br /> result in kernel BUG. In order to fix this without fixing every call<br /> site, just leak a couple of bytes in such corner case.

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 /> block, bfq: don&amp;#39;t move oom_bfqq<br /> <br /> Our test report a UAF:<br /> <br /> [ 2073.019181] ==================================================================<br /> [ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168<br /> [ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584<br /> [ 2073.019192]<br /> [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5<br /> [ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015<br /> [ 2073.019200] Call trace:<br /> [ 2073.019203] dump_backtrace+0x0/0x310<br /> [ 2073.019206] show_stack+0x28/0x38<br /> [ 2073.019210] dump_stack+0xec/0x15c<br /> [ 2073.019216] print_address_description+0x68/0x2d0<br /> [ 2073.019220] kasan_report+0x238/0x2f0<br /> [ 2073.019224] __asan_store8+0x88/0xb0<br /> [ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168<br /> [ 2073.019233] bfq_put_async_queues+0xbc/0x208<br /> [ 2073.019236] bfq_pd_offline+0x178/0x238<br /> [ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420<br /> [ 2073.019244] bfq_exit_queue+0x128/0x178<br /> [ 2073.019249] blk_mq_exit_sched+0x12c/0x160<br /> [ 2073.019252] elevator_exit+0xc8/0xd0<br /> [ 2073.019256] blk_exit_queue+0x50/0x88<br /> [ 2073.019259] blk_cleanup_queue+0x228/0x3d8<br /> [ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk]<br /> [ 2073.019274] null_exit+0x90/0x114 [null_blk]<br /> [ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0<br /> [ 2073.019282] el0_svc_common+0xc8/0x320<br /> [ 2073.019287] el0_svc_handler+0xf8/0x160<br /> [ 2073.019290] el0_svc+0x10/0x218<br /> [ 2073.019291]<br /> [ 2073.019294] Allocated by task 14163:<br /> [ 2073.019301] kasan_kmalloc+0xe0/0x190<br /> [ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418<br /> [ 2073.019308] bfq_pd_alloc+0x54/0x118<br /> [ 2073.019313] blkcg_activate_policy+0x250/0x460<br /> [ 2073.019317] bfq_create_group_hierarchy+0x38/0x110<br /> [ 2073.019321] bfq_init_queue+0x6d0/0x948<br /> [ 2073.019325] blk_mq_init_sched+0x1d8/0x390<br /> [ 2073.019330] elevator_switch_mq+0x88/0x170<br /> [ 2073.019334] elevator_switch+0x140/0x270<br /> [ 2073.019338] elv_iosched_store+0x1a4/0x2a0<br /> [ 2073.019342] queue_attr_store+0x90/0xe0<br /> [ 2073.019348] sysfs_kf_write+0xa8/0xe8<br /> [ 2073.019351] kernfs_fop_write+0x1f8/0x378<br /> [ 2073.019359] __vfs_write+0xe0/0x360<br /> [ 2073.019363] vfs_write+0xf0/0x270<br /> [ 2073.019367] ksys_write+0xdc/0x1b8<br /> [ 2073.019371] __arm64_sys_write+0x50/0x60<br /> [ 2073.019375] el0_svc_common+0xc8/0x320<br /> [ 2073.019380] el0_svc_handler+0xf8/0x160<br /> [ 2073.019383] el0_svc+0x10/0x218<br /> [ 2073.019385]<br /> [ 2073.019387] Freed by task 72584:<br /> [ 2073.019391] __kasan_slab_free+0x120/0x228<br /> [ 2073.019394] kasan_slab_free+0x10/0x18<br /> [ 2073.019397] kfree+0x94/0x368<br /> [ 2073.019400] bfqg_put+0x64/0xb0<br /> [ 2073.019404] bfqg_and_blkg_put+0x90/0xb0<br /> [ 2073.019408] bfq_put_queue+0x220/0x228<br /> [ 2073.019413] __bfq_put_async_bfqq+0x98/0x168<br /> [ 2073.019416] bfq_put_async_queues+0xbc/0x208<br /> [ 2073.019420] bfq_pd_offline+0x178/0x238<br /> [ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420<br /> [ 2073.019429] bfq_exit_queue+0x128/0x178<br /> [ 2073.019433] blk_mq_exit_sched+0x12c/0x160<br /> [ 2073.019437] elevator_exit+0xc8/0xd0<br /> [ 2073.019440] blk_exit_queue+0x50/0x88<br /> [ 2073.019443] blk_cleanup_queue+0x228/0x3d8<br /> [ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk]<br /> [ 2073.019459] null_exit+0x90/0x114 [null_blk]<br /> [ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0<br /> [ 2073.019467] el0_svc_common+0xc8/0x320<br /> [ 2073.019471] el0_svc_handler+0xf8/0x160<br /> [ 2073.019474] el0_svc+0x10/0x218<br /> [ 2073.019475]<br /> [ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00<br /> which belongs to the cache kmalloc-1024 of size 1024<br /> [ 2073.019484] The buggy address is located 552 bytes inside of<br /> 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300)<br /> [ 2073.019486] The buggy address belongs to the page:<br /> [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0<br /> [ 2073.020123] flags: 0x7ffff0000008100(slab|head)<br /> [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00<br /> [ 2073.020409] ra<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LSM: general protection fault in legacy_parse_param<br /> <br /> The usual LSM hook "bail on fail" scheme doesn&amp;#39;t work for cases where<br /> a security module may return an error code indicating that it does not<br /> recognize an input. In this particular case Smack sees a mount option<br /> that it recognizes, and returns 0. A call to a BPF hook follows, which<br /> returns -ENOPARAM, which confuses the caller because Smack has processed<br /> its data.<br /> <br /> The SELinux hook incorrectly returns 1 on success. There was a time<br /> when this was correct, however the current expectation is that it<br /> return 0 on success. This is repaired.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: add vlan list lock to protect vlan list<br /> <br /> When adding port base VLAN, vf VLAN need to remove from HW and modify<br /> the vlan state in vf VLAN list as false. If the periodicity task is<br /> freeing the same node, it may cause "use after free" error.<br /> This patch adds a vlan list lock to protect the vlan list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_ct: fix ref leak when switching zones<br /> <br /> When switching zones or network namespaces without doing a ct clear in<br /> between, it is now leaking a reference to the old ct entry. That&amp;#39;s<br /> because tcf_ct_skb_nfct_cached() returns false and<br /> tcf_ct_flow_table_lookup() may simply overwrite it.<br /> <br /> The fix is to, as the ct entry is not reusable, free it already at<br /> tcf_ct_skb_nfct_cached().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sparx5: switchdev: fix possible NULL pointer dereference<br /> <br /> As the possible failure of the allocation, devm_kzalloc() may return NULL<br /> pointer.<br /> Therefore, it should be better to check the &amp;#39;db&amp;#39; in order to prevent<br /> the dereference of NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe<br /> <br /> This node pointer is returned by of_parse_phandle() with refcount<br /> incremented in this function. Calling of_node_put() to avoid<br /> the refcount leak.