CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47565 – scsi: mpt3sas: Fix kernel panic during drive powercycle test
https://notcve.org/view.php?id=CVE-2021-47565
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix kernel panic during drive powercycle test While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: mpt3sas: solucionó el pánico del kernel durante la prueba de ciclo de energía de la unidad. Mientras se recorre la lista sdev de shost, es posible que una de las unidades se esté eliminando y su objeto sas_target se libere pero su objeto sdev permanece intacta. En consecuencia, puede ocurrir un pánico en el kernel mientras el controlador intenta acceder al campo sas_address del objeto sas_target sin verificar también si el objeto sas_target es NULL. • https://git.kernel.org/stable/c/f92363d12359498f9a9960511de1a550f0ec41c2 https://git.kernel.org/stable/c/5d4d50b1f159a5ebab7617f47121b4370aa58afe https://git.kernel.org/stable/c/58ef2c7a6de13721865d84b80eecf56d6cba0937 https://git.kernel.org/stable/c/dd035ca0e7a142870a970d46b1d19276cfe2bc8c https://git.kernel.org/stable/c/0d4b29eaadc1f59cec0c7e85eae77d08fcca9824 https://git.kernel.org/stable/c/7e324f734a914957b8cc3ff4b4c9f0409558adb5 https://git.kernel.org/stable/c/2bf9c5a5039c8f4b037236aed505e6a25c1d5f7b https://git.kernel.org/stable/c/8485649a7655e791a6e4e9f15b4d30fda •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47564 – net: marvell: prestera: fix double free issue on err path
https://notcve.org/view.php?id=CVE-2021-47564
In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix double free issue on err path fix error path handling in prestera_bridge_port_join() that cases prestera driver to crash (see below). Trace: Internal error: Oops: 96000044 [#1] SMP Modules linked in: prestera_pci prestera uio_pdrv_genirq CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : prestera_bridge_destroy+0x2c/0xb0 [prestera] lr : prestera_bridge_port_join+0x2cc/0x350 [prestera] sp : ffff800011a1b0f0 ... x2 : ffff000109ca6c80 x1 : dead000000000100 x0 : dead000000000122 Call trace: prestera_bridge_destroy+0x2c/0xb0 [prestera] prestera_bridge_port_join+0x2cc/0x350 [prestera] prestera_netdev_port_event.constprop.0+0x3c4/0x450 [prestera] prestera_netdev_event_handler+0xf4/0x110 [prestera] raw_notifier_call_chain+0x54/0x80 call_netdevice_notifiers_info+0x54/0xa0 __netdev_upper_dev_link+0x19c/0x380 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: marvell: prestera: corrige el problema de doble liberación en la ruta de error corrige el manejo de la ruta de error en prestera_bridge_port_join() que hace que el controlador de prestera falle (ver más abajo). Seguimiento: Error interno: Ups: 96000044 [#1] Módulos SMP vinculados en: prestera_pci prestera uio_pdrv_genirq CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: prestera_bridge_destroy+0x2c/0xb0 [prestera] lr: prestera_bridge_port_join+0x2cc/0x350 [prestera] sp: ffff800011a1b0f0... x2: ffff000109ca6c80 x1: dead000000000100 x0: dead00000 0000122 Rastreo de llamadas: prestera_bridge_destroy+0x2c/0xb0 [prestera] prestera_bridge_port_join+0x2cc/0x350 [prestera] prestera_netdev_port_event.constprop.0+0x3c4/0x450 [prestera] prestera_netdev_event_handler+0xf4/0x110 [prestera] raw_notifier_call_chain+0x54/0x80 call_netdevice_notifiers_info+0 x54/0xa0 __netdev_upper_dev_link+0x19c/0x380 • https://git.kernel.org/stable/c/e1189d9a5fbec8153dbe03f3589bc2baa96694e2 https://git.kernel.org/stable/c/5dca8eff4627315df98feec09fff9dfe3356325e https://git.kernel.org/stable/c/03e5203d2161a00afe4d97d206d2293e40b2f253 https://git.kernel.org/stable/c/e8d032507cb7912baf1d3e0af54516f823befefd •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47563 – ice: avoid bpf_prog refcount underflow
https://notcve.org/view.php?id=CVE-2021-47563
In the Linux kernel, the following vulnerability has been resolved: ice: avoid bpf_prog refcount underflow Ice driver has the routines for managing XDP resources that are shared between ndo_bpf op and VSI rebuild flow. The latter takes place for example when user changes queue count on an interface via ethtool's set_channels(). There is an issue around the bpf_prog refcounting when VSI is being rebuilt - since ice_prepare_xdp_rings() is called with vsi->xdp_prog as an argument that is used later on by ice_vsi_assign_bpf_prog(), same bpf_prog pointers are swapped with each other. Then it is also interpreted as an 'old_prog' which in turn causes us to call bpf_prog_put on it that will decrement its refcount. Below splat can be interpreted in a way that due to zero refcount of a bpf_prog it is wiped out from the system while kernel still tries to refer to it: [ 481.069429] BUG: unable to handle page fault for address: ffffc9000640f038 [ 481.077390] #PF: supervisor read access in kernel mode [ 481.083335] #PF: error_code(0x0000) - not-present page [ 481.089276] PGD 100000067 P4D 100000067 PUD 1001cb067 PMD 106d2b067 PTE 0 [ 481.097141] Oops: 0000 [#1] PREEMPT SMP PTI [ 481.101980] CPU: 12 PID: 3339 Comm: sudo Tainted: G OE 5.15.0-rc5+ #1 [ 481.110840] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016 [ 481.122021] RIP: 0010:dev_xdp_prog_id+0x25/0x40 [ 481.127265] Code: 80 00 00 00 00 0f 1f 44 00 00 89 f6 48 c1 e6 04 48 01 fe 48 8b 86 98 08 00 00 48 85 c0 74 13 48 8b 50 18 31 c0 48 85 d2 74 07 <48> 8b 42 38 8b 40 20 c3 48 8b 96 90 08 00 00 eb e8 66 2e 0f 1f 84 [ 481.148991] RSP: 0018:ffffc90007b63868 EFLAGS: 00010286 [ 481.155034] RAX: 0000000000000000 RBX: ffff889080824000 RCX: 0000000000000000 [ 481.163278] RDX: ffffc9000640f000 RSI: ffff889080824010 RDI: ffff889080824000 [ 481.171527] RBP: ffff888107af7d00 R08: 0000000000000000 R09: ffff88810db5f6e0 [ 481.179776] R10: 0000000000000000 R11: ffff8890885b9988 R12: ffff88810db5f4bc [ 481.188026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 481.196276] FS: 00007f5466d5bec0(0000) GS:ffff88903fb00000(0000) knlGS:0000000000000000 [ 481.205633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 481.212279] CR2: ffffc9000640f038 CR3: 000000014429c006 CR4: 00000000003706e0 [ 481.220530] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 481.228771] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 481.237029] Call Trace: [ 481.239856] rtnl_fill_ifinfo+0x768/0x12e0 [ 481.244602] rtnl_dump_ifinfo+0x525/0x650 [ 481.249246] ? __alloc_skb+0xa5/0x280 [ 481.253484] netlink_dump+0x168/0x3c0 [ 481.257725] netlink_recvmsg+0x21e/0x3e0 [ 481.262263] ____sys_recvmsg+0x87/0x170 [ 481.266707] ? • https://git.kernel.org/stable/c/efc2214b6047b6f5b4ca53151eba62521b9452d6 https://git.kernel.org/stable/c/e65a8707b4cd756d26d246bb2b9fab06eebafac1 https://git.kernel.org/stable/c/1f10b09ccc832698ef4624a6ab9a213b6ccbda76 https://git.kernel.org/stable/c/f65ee535df775a13a1046c0a0b2d72db342f8a5b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47562 – ice: fix vsi->txq_map sizing
https://notcve.org/view.php?id=CVE-2021-47562
In the Linux kernel, the following vulnerability has been resolved: ice: fix vsi->txq_map sizing The approach of having XDP queue per CPU regardless of user's setting exposed a hidden bug that could occur in case when Rx queue count differ from Tx queue count. Currently vsi->txq_map's size is equal to the doubled vsi->alloc_txq, which is not correct due to the fact that XDP rings were previously based on the Rx queue count. Below splat can be seen when ethtool -L is used and XDP rings are configured: [ 682.875339] BUG: kernel NULL pointer dereference, address: 000000000000000f [ 682.883403] #PF: supervisor read access in kernel mode [ 682.889345] #PF: error_code(0x0000) - not-present page [ 682.895289] PGD 0 P4D 0 [ 682.898218] Oops: 0000 [#1] PREEMPT SMP PTI [ 682.903055] CPU: 42 PID: 2878 Comm: ethtool Tainted: G OE 5.15.0-rc5+ #1 [ 682.912214] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016 [ 682.923380] RIP: 0010:devres_remove+0x44/0x130 [ 682.928527] Code: 49 89 f4 55 48 89 fd 4c 89 ff 53 48 83 ec 10 e8 92 b9 49 00 48 8b 9d a8 02 00 00 48 8d 8d a0 02 00 00 49 89 c2 48 39 cb 74 0f <4c> 3b 63 10 74 25 48 8b 5b 08 48 39 cb 75 f1 4c 89 ff 4c 89 d6 e8 [ 682.950237] RSP: 0018:ffffc90006a679f0 EFLAGS: 00010002 [ 682.956285] RAX: 0000000000000286 RBX: ffffffffffffffff RCX: ffff88908343a370 [ 682.964538] RDX: 0000000000000001 RSI: ffffffff81690d60 RDI: 0000000000000000 [ 682.972789] RBP: ffff88908343a0d0 R08: 0000000000000000 R09: 0000000000000000 [ 682.981040] R10: 0000000000000286 R11: 3fffffffffffffff R12: ffffffff81690d60 [ 682.989282] R13: ffffffff81690a00 R14: ffff8890819807a8 R15: ffff88908343a36c [ 682.997535] FS: 00007f08c7bfa740(0000) GS:ffff88a03fd00000(0000) knlGS:0000000000000000 [ 683.006910] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 683.013557] CR2: 000000000000000f CR3: 0000001080a66003 CR4: 00000000003706e0 [ 683.021819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 683.030075] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 683.038336] Call Trace: [ 683.041167] devm_kfree+0x33/0x50 [ 683.045004] ice_vsi_free_arrays+0x5e/0xc0 [ice] [ 683.050380] ice_vsi_rebuild+0x4c8/0x750 [ice] [ 683.055543] ice_vsi_recfg_qs+0x9a/0x110 [ice] [ 683.060697] ice_set_channels+0x14f/0x290 [ice] [ 683.065962] ethnl_set_channels+0x333/0x3f0 [ 683.070807] genl_family_rcv_msg_doit+0xea/0x150 [ 683.076152] genl_rcv_msg+0xde/0x1d0 [ 683.080289] ? channels_prepare_data+0x60/0x60 [ 683.085432] ? • https://git.kernel.org/stable/c/efc2214b6047b6f5b4ca53151eba62521b9452d6 https://git.kernel.org/stable/c/1eb5395add786613c7c5579d3947aa0b8f0ec241 https://git.kernel.org/stable/c/992ba40a67638dfe2772b84dfc8168dc328d5c4c https://git.kernel.org/stable/c/792b2086584f25d84081a526beee80d103c2a913 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47561 – i2c: virtio: disable timeout handling
https://notcve.org/view.php?id=CVE-2021-47561
In the Linux kernel, the following vulnerability has been resolved: i2c: virtio: disable timeout handling If a timeout is hit, it can result is incorrect data on the I2C bus and/or memory corruptions in the guest since the device can still be operating on the buffers it was given while the guest has freed them. Here is, for example, the start of a slub_debug splat which was triggered on the next transfer after one transfer was forced to timeout by setting a breakpoint in the backend (rust-vmm/vhost-device): BUG kmalloc-1k (Not tainted): Poison overwritten First byte 0x1 instead of 0x6b Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29 __kmalloc+0xc2/0x1c9 virtio_i2c_xfer+0x65/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29 kfree+0x1bd/0x1cc virtio_i2c_xfer+0x32e/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 There is no simple fix for this (the driver would have to always create bounce buffers and hold on to them until the device eventually returns the buffers), so just disable the timeout support for now. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: virtio: deshabilita el manejo del tiempo de espera Si se alcanza un tiempo de espera, puede resultar en datos incorrectos en el bus I2C y/o daños en la memoria del invitado, ya que el dispositivo aún puede estar funcionando. en los buffers que se le dieron mientras el huésped los liberó. Aquí está, por ejemplo, el inicio de un splat slub_debug que se activó en la siguiente transferencia después de que se obligó a que una transferencia expirara estableciendo un punto de interrupción en el backend (rust-vmm/vhost-device): ERROR kmalloc-1k (No contaminado ): Veneno sobrescrito Primer byte 0x1 en lugar de 0x6b Asignado en virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29 __kmalloc+0xc2/0x1c9 virtio_i2c_xfer+0x65/0x35c __i2c_transfer+0x429/0x57d 0x115/0x134 i2cdev_ioctl_rdwr+0x16a/ 0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Liberado en virtio_i2c_xfer+0x32e/0x35c edad=244 cpu=0 pid=29 kfree+0x1bd/0x1cc x32e/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115 /0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 No existe una solución sencilla para esto (el controlador siempre tendría que crear búferes de rebote y conservarlos hasta que el dispositivo finalmente devuelva el búferes), así que simplemente deshabilite el soporte de tiempo de espera por ahora. • https://git.kernel.org/stable/c/3cfc88380413d20f777dc6648a38f683962e52bf https://git.kernel.org/stable/c/cc432b0727ce404cc13e8f6b5ce29f412c3f9f1f https://git.kernel.org/stable/c/84e1d0bf1d7121759622dabf8fbef4c99ad597c5 •