Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nVMX: Always make an attempt to map eVMCS after migration<br /> <br /> When enlightened VMCS is in use and nested state is migrated with<br /> vmx_get_nested_state()/vmx_set_nested_state() KVM can&amp;#39;t map evmcs<br /> page right away: evmcs gpa is not &amp;#39;struct kvm_vmx_nested_state_hdr&amp;#39;<br /> and we can&amp;#39;t read it from VP assist page because userspace may decide<br /> to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state<br /> (and QEMU, for example, does exactly that). To make sure eVMCS is<br /> mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES<br /> request.<br /> <br /> Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES<br /> on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to<br /> nested_vmx_vmexit() to make sure MSR permission bitmap is not switched<br /> when an immediate exit from L2 to L1 happens right after migration (caused<br /> by a pending event, for example). Unfortunately, in the exact same<br /> situation we still need to have eVMCS mapped so<br /> nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS.<br /> <br /> As a band-aid, restore nested_get_evmcs_page() when clearing<br /> KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The &amp;#39;fix&amp;#39; is far<br /> from being ideal as we can&amp;#39;t easily propagate possible failures and even if<br /> we could, this is most likely already too late to do so. The whole<br /> &amp;#39;KVM_REQ_GET_NESTED_STATE_PAGES&amp;#39; idea for mapping eVMCS after migration<br /> seems to be fragile as we diverge too much from the &amp;#39;native&amp;#39; path when<br /> vmptr loading happens on vmx_set_nested_state().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: core: fix ioctl handlers removal<br /> <br /> Currently ioctl handlers are removed twice. For the first time during<br /> iio_device_unregister() then later on inside<br /> iio_device_unregister_eventset() and iio_buffers_free_sysfs_and_mask().<br /> Double free leads to kernel panic.<br /> <br /> Fix this by not touching ioctl handlers list directly but rather<br /> letting code responsible for registration call the matching cleanup<br /> routine itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4<br /> <br /> commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects<br /> in PD mode") introduced retrieval of the PDOs when connected to a<br /> PD-capable source. But only the first 4 PDOs are received since<br /> that is the maximum number that can be fetched at a time given the<br /> MESSAGE_IN length limitation (16 bytes). However, as per the PD spec<br /> a connected source may advertise up to a maximum of 7 PDOs.<br /> <br /> If such a source is connected it&amp;#39;s possible the PPM could have<br /> negotiated a power contract with one of the PDOs at index greater<br /> than 4, and would be reflected in the request data object&amp;#39;s (RDO)<br /> object position field. This would result in an out-of-bounds access<br /> when the rdo_index() is used to index into the src_pdos array in<br /> ucsi_psy_get_voltage_now().<br /> <br /> With the help of the UBSAN -fsanitize=array-bounds checker enabled<br /> this exact issue is revealed when connecting to a PD source adapter<br /> that advertise 5 PDOs and the PPM enters a contract having selected<br /> the 5th one.<br /> <br /> [ 151.545106][ T70] Unexpected kernel BRK exception at EL1<br /> [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP<br /> ...<br /> [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c<br /> [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328<br /> ...<br /> [ 151.545542][ T70] Call trace:<br /> [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c<br /> [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0<br /> [ 151.545550][ T70] dev_uevent+0x200/0x384<br /> [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8<br /> [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c<br /> [ 151.545562][ T70] process_one_work+0x244/0x6f0<br /> [ 151.545564][ T70] worker_thread+0x3e0/0xa64<br /> <br /> We can resolve this by instead retrieving and storing up to the<br /> maximum of 7 PDOs in the con-&gt;src_pdos array. This would involve<br /> two calls to the GET_PDOS command.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: Fix NULL pointer in flush_workqueue<br /> <br /> Open /dev/nbdX first, the config_refs will be 1 and<br /> the pointers in nbd_device are still null. Disconnect<br /> /dev/nbdX, then reference a null recv_workq. The<br /> protection by config_refs in nbd_genl_disconnect is useless.<br /> <br /> [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> [ 656.368943] #PF: supervisor write access in kernel mode<br /> [ 656.369844] #PF: error_code(0x0002) - not-present page<br /> [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0<br /> [ 656.371693] Oops: 0002 [#1] SMP<br /> [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1<br /> [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014<br /> [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60<br /> [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f b1 55 d<br /> [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246<br /> [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020<br /> [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318<br /> [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40<br /> [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00<br /> [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000<br /> [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0<br /> [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 656.384927] Call Trace:<br /> [ 656.385111] flush_workqueue+0x92/0x6c0<br /> [ 656.385395] nbd_disconnect_and_put+0x81/0xd0<br /> [ 656.385716] nbd_genl_disconnect+0x125/0x2a0<br /> [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0<br /> [ 656.386422] genl_rcv_msg+0xfc/0x2b0<br /> [ 656.386685] ? nbd_ioctl+0x490/0x490<br /> [ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0<br /> [ 656.387354] netlink_rcv_skb+0x62/0x180<br /> [ 656.387638] genl_rcv+0x34/0x60<br /> [ 656.387874] netlink_unicast+0x26d/0x590<br /> [ 656.388162] netlink_sendmsg+0x398/0x6c0<br /> [ 656.388451] ? netlink_rcv_skb+0x180/0x180<br /> [ 656.388750] ____sys_sendmsg+0x1da/0x320<br /> [ 656.389038] ? ____sys_recvmsg+0x130/0x220<br /> [ 656.389334] ___sys_sendmsg+0x8e/0xf0<br /> [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0<br /> [ 656.389889] ? handle_mm_fault+0x1671/0x21d0<br /> [ 656.390201] __sys_sendmsg+0x6d/0xe0<br /> [ 656.390464] __x64_sys_sendmsg+0x23/0x30<br /> [ 656.390751] do_syscall_64+0x45/0x70<br /> [ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> To fix it, just add if (nbd-&gt;recv_workq) to nbd_disconnect_and_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: xiic: fix reference leak when pm_runtime_get_sync fails<br /> <br /> The PM reference count is not expected to be incremented on<br /> return in xiic_xfer and xiic_i2c_remove.<br /> <br /> However, pm_runtime_get_sync will increment the PM reference<br /> count even failed. Forgetting to putting operation will result<br /> in a reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: stm32f7: fix reference leak when pm_runtime_get_sync fails<br /> <br /> The PM reference count is not expected to be incremented on<br /> return in these stm32f7_i2c_xx serious functions.<br /> <br /> However, pm_runtime_get_sync will increment the PM reference<br /> count even failed. Forgetting to putting operation will result<br /> in a reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: sprd: fix reference leak when pm_runtime_get_sync fails<br /> <br /> The PM reference count is not expected to be incremented on<br /> return in sprd_i2c_master_xfer() and sprd_i2c_remove().<br /> <br /> However, pm_runtime_get_sync will increment the PM reference<br /> count even failed. Forgetting to putting operation will result<br /> in a reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: fix reference leak when pm_runtime_get_sync fails<br /> <br /> In i2c_imx_xfer() and i2c_imx_remove(), the pm reference count<br /> is not expected to be incremented on return.<br /> <br /> However, pm_runtime_get_sync will increment pm reference count<br /> even failed. Forgetting to putting operation will result in a<br /> reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails<br /> <br /> The PM reference count is not expected to be incremented on<br /> return in lpi2c_imx_master_enable.<br /> <br /> However, pm_runtime_get_sync will increment the PM reference<br /> count even failed. Forgetting to putting operation will result<br /> in a reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: img-scb: fix reference leak when pm_runtime_get_sync fails<br /> <br /> The PM reference count is not expected to be incremented on<br /> return in functions img_i2c_xfer and img_i2c_init.<br /> <br /> However, pm_runtime_get_sync will increment the PM reference<br /> count even failed. Forgetting to putting operation will result<br /> in a reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: cadence: fix reference leak when pm_runtime_get_sync fails<br /> <br /> The PM reference count is not expected to be incremented on<br /> return in functions cdns_i2c_master_xfer and cdns_reg_slave.<br /> <br /> However, pm_runtime_get_sync will increment pm usage counter<br /> even failed. Forgetting to putting operation will result in a<br /> reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: [next] staging: media: atomisp: fix memory leak of object flash<br /> <br /> In the case where the call to lm3554_platform_data_func returns an<br /> error there is a memory leak on the error return path of object<br /> flash. Fix this by adding an error return path that will free<br /> flash and rename labels fail2 to fail3 and fail1 to fail2.