CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2021-46981 – nbd: Fix NULL pointer in flush_workqueue
https://notcve.org/view.php?id=CVE-2021-46981
In the Linux kernel, the following vulnerability has been resolved: nbd: Fix NULL pointer in flush_workqueue Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: error_code(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 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 <f0> 48 0f b1 55 d [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ? nbd_ioctl+0x490/0x490 [ 656.386954] ? • https://git.kernel.org/stable/c/e9e006f5fcf2bab59149cb38a48a4817c1b538b4 https://git.kernel.org/stable/c/0b584bf573ae59021069c056c22d65d5721910cb https://git.kernel.org/stable/c/d1db913b044f0a0693d8ee283d26b81d536efcd5 https://git.kernel.org/stable/c/9f0f39c92e4f50189155dfb13bb5524372e40eba https://git.kernel.org/stable/c/e83a26a49356a3dbd4f54102abe17fc594643698 https://git.kernel.org/stable/c/92ec11cccb7fc14331e000ab2337f60aa433433e https://git.kernel.org/stable/c/b3ead320dce6c7d7206103deca766b317591c286 https://git.kernel.org/stable/c/1c4962df938891af9ab4775f5224ef860 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46980 – usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4
https://notcve.org/view.php?id=CVE-2021-46980
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4 commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs. If such a source is connected it's possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object's (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now(). With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one. [ 151.545106][ T70] Unexpected kernel BRK exception at EL1 [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Call trace: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0 [ 151.545550][ T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] process_one_work+0x244/0x6f0 [ 151.545564][ T70] worker_thread+0x3e0/0xa64 We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command. • https://git.kernel.org/stable/c/4dbc6a4ef06d6a79ff91be6fc2e90f8660031ce0 https://git.kernel.org/stable/c/e5366bea0277425e1868ba20eeb27c879d5a6e2d https://git.kernel.org/stable/c/a453bfd7ef15fd9d524004d3ca7b05353a302911 https://git.kernel.org/stable/c/5e9c6f58b01e6fdfbc740390c01f542a35c97e57 https://git.kernel.org/stable/c/1f4642b72be79757f050924a9b9673b6a02034bc •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-46979 – iio: core: fix ioctl handlers removal
https://notcve.org/view.php?id=CVE-2021-46979
In the Linux kernel, the following vulnerability has been resolved: iio: core: fix ioctl handlers removal Currently ioctl handlers are removed twice. For the first time during iio_device_unregister() then later on inside iio_device_unregister_eventset() and iio_buffers_free_sysfs_and_mask(). Double free leads to kernel panic. Fix this by not touching ioctl handlers list directly but rather letting code responsible for registration call the matching cleanup routine itself. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: core: arreglar la eliminación de los controladores ioctl Actualmente, los controladores ioctl se eliminan dos veces. Por primera vez durante iio_device_unregister() y luego dentro de iio_device_unregister_eventset() y iio_buffers_free_sysfs_and_mask(). La doble liberación conduce al pánico en el kernel. • https://git.kernel.org/stable/c/8dedcc3eee3aceb37832176f0a1b03d5687acda3 https://git.kernel.org/stable/c/11e1cae5da4096552f7c091476cbadbc0d1817da https://git.kernel.org/stable/c/ab6c935ba3a04317632f3b8b68675bdbaf395303 https://git.kernel.org/stable/c/901f84de0e16bde10a72d7eb2f2eb73fcde8fa1a •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46978 – KVM: nVMX: Always make an attempt to map eVMCS after migration
https://notcve.org/view.php?id=CVE-2021-46978
In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always make an attempt to map eVMCS after migration When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state(). • https://git.kernel.org/stable/c/0faceb7d6dda6f370ff1fa0464d7180f7e5cb417 https://git.kernel.org/stable/c/f2c7ef3ba9556d62a7e2bb23b563c6510007d55c https://git.kernel.org/stable/c/c8bf64e3fb77cc19bad146fbe26651985b117194 https://git.kernel.org/stable/c/200a45649ab7361bc80c70aebf7165b64f9a6c9f https://git.kernel.org/stable/c/bd0e8455b85b651a4c77de9616e307129b15aaa7 https://git.kernel.org/stable/c/f5c7e8425f18fdb9bdb7d13340651d7876890329 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46977 – KVM: VMX: Disable preemption when probing user return MSRs
https://notcve.org/view.php?id=CVE-2021-46977
In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Disable preemption when probing user return MSRs Disable preemption when probing a user return MSR via RDSMR/WRMSR. If the MSR holds a different value per logical CPU, the WRMSR could corrupt the host's value if KVM is preempted between the RDMSR and WRMSR, and then rescheduled on a different CPU. Opportunistically land the helper in common x86, SVM will use the helper in a future commit. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: VMX: deshabilite la preferencia al sondear los MSR devueltos por el usuario. Deshabilite la preferencia al sondear el MSR devuelto por un usuario a través de RDSMR/WRMSR. Si MSR tiene un valor diferente por CPU lógica, WRMSR podría dañar el valor del host si KVM se adelanta entre RDMSR y WRMSR y luego se reprograma en una CPU diferente. • https://git.kernel.org/stable/c/4be5341026246870818e28b53202b001426a5aec https://git.kernel.org/stable/c/31f29749ee970c251b3a7e5b914108425940d089 https://git.kernel.org/stable/c/5adcdeb57007ccf8ab7ac20bf787ffb6fafb1a94 https://git.kernel.org/stable/c/e3ea1895df719c4ef87862501bb10d95f4177bed https://git.kernel.org/stable/c/5104d7ffcf24749939bea7fdb5378d186473f890 •