CVSS: 7.3EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47441 – mlxsw: thermal: Fix out-of-bounds memory accesses
https://notcve.org/view.php?id=CVE-2021-47441
In the Linux kernel, the following vulnerability has been resolved: mlxsw: thermal: Fix out-of-bounds memory accesses Currently, mlxsw allows cooling states to be set above the maximum cooling state supported by the driver: # cat /sys/class/thermal/thermal_zone2/cdev0/type mlxsw_fan # cat /sys/class/thermal/thermal_zone2/cdev0/max_state 10 # echo 18 > /sys/class/thermal/thermal_zone2/cdev0/cur_state # echo $? 0 This results in out-of-bounds memory accesses when thermal state transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the transition table is accessed with a too large index (state) [1]. According to the thermal maintainer, it is the responsibility of the driver to reject such operations [2]. Therefore, return an error when the state to be set exceeds the maximum cooling state supported by the driver. To avoid dead code, as suggested by the thermal maintainer [3], partially revert commit a421ce088ac8 ("mlxsw: core: Extend cooling device with cooling levels") that tried to interpret these invalid cooling states (above the maximum) in a special way. The cooling levels array is not removed in order to prevent the fans going below 20% PWM, which would cause them to get stuck at 0% PWM. [1] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290 Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5 CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122 Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016 Workqueue: events_freezable_power_ thermal_zone_device_check Call Trace: dump_stack_lvl+0x8b/0xb3 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b thermal_cooling_device_stats_update+0x271/0x290 __thermal_cdev_update+0x15e/0x4e0 thermal_cdev_update+0x9f/0xe0 step_wise_throttle+0x770/0xee0 thermal_zone_device_update+0x3f6/0xdf0 process_one_work+0xa42/0x1770 worker_thread+0x62f/0x13e0 kthread+0x3ee/0x4e0 ret_from_fork+0x1f/0x30 Allocated by task 1: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 thermal_cooling_device_setup_sysfs+0x153/0x2c0 __thermal_cooling_device_register.part.0+0x25b/0x9c0 thermal_cooling_device_register+0xb3/0x100 mlxsw_thermal_init+0x5c5/0x7e0 __mlxsw_core_bus_device_register+0xcb3/0x19c0 mlxsw_core_bus_device_register+0x56/0xb0 mlxsw_pci_probe+0x54f/0x710 local_pci_probe+0xc6/0x170 pci_device_probe+0x2b2/0x4d0 really_probe+0x293/0xd10 __driver_probe_device+0x2af/0x440 driver_probe_device+0x51/0x1e0 __driver_attach+0x21b/0x530 bus_for_each_dev+0x14c/0x1d0 bus_add_driver+0x3ac/0x650 driver_register+0x241/0x3d0 mlxsw_sp_module_init+0xa2/0x174 do_one_initcall+0xee/0x5f0 kernel_init_freeable+0x45a/0x4de kernel_init+0x1f/0x210 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff8881052f7800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 1016 bytes inside of 1024-byte region [ffff8881052f7800, ffff8881052f7c00) The buggy address belongs to the page: page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0 head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x200000000010200(slab|head|node=0|zone=2) raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67- ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: Thermal: corrige accesos a memoria fuera de los límites Actualmente, mlxsw permite establecer estados de enfriamiento por encima del estado de enfriamiento máximo admitido por el controlador: # cat /sys/class/ Thermal/thermal_zone2/cdev0/type mlxsw_fan # cat /sys/class/thermal/thermal_zone2/cdev0/max_state 10 # echo 18 > /sys/class/thermal/thermal_zone2/cdev0/cur_state # echo $? 0 Esto da como resultado accesos a la memoria fuera de los límites cuando las estadísticas de transición de estado térmico están habilitadas (CONFIG_THERMAL_STATISTICS=y), ya que se accede a la tabla de transición con un índice (estado) demasiado grande [1]. • https://git.kernel.org/stable/c/a50c1e35650b929500bd89be61c89d95a267ce56 https://git.kernel.org/stable/c/ae0993739e14a102d506aa09e11b0065f3144f10 https://git.kernel.org/stable/c/e59d839743b50cb1d3f42a786bea48cc5621d254 https://git.kernel.org/stable/c/df8e58716afb3bee2b59de66b1ba1033f2e26303 https://git.kernel.org/stable/c/332fdf951df8b870e3da86b122ae304e2aabe88c https://access.redhat.com/security/cve/CVE-2021-47441 https://bugzilla.redhat.com/show_bug.cgi?id=2282851 • CWE-787: Out-of-bounds Write •
CVSS: 2.3EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47440 – net: encx24j600: check error in devm_regmap_init_encx24j600
https://notcve.org/view.php?id=CVE-2021-47440
In the Linux kernel, the following vulnerability has been resolved: net: encx24j600: check error in devm_regmap_init_encx24j600 devm_regmap_init may return error which caused by like out of memory, this will results in null pointer dereference later when reading or writing register: general protection fault in encx24j600_spi_probe KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540 Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00 RSP: 0018:ffffc900010476b8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000 RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094 RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001 R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08 FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459 spi_probe drivers/spi/spi.c:397 really_probe drivers/base/dd.c:517 __driver_probe_device drivers/base/dd.c:751 driver_probe_device drivers/base/dd.c:782 __device_attach_driver drivers/base/dd.c:899 bus_for_each_drv drivers/base/bus.c:427 __device_attach drivers/base/dd.c:971 bus_probe_device drivers/base/bus.c:487 device_add drivers/base/core.c:3364 __spi_add_device drivers/spi/spi.c:599 spi_add_device drivers/spi/spi.c:641 spi_new_device drivers/spi/spi.c:717 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e] dev_attr_store drivers/base/core.c:2074 sysfs_kf_write fs/sysfs/file.c:139 kernfs_fop_write_iter fs/kernfs/file.c:300 new_sync_write fs/read_write.c:508 (discriminator 4) vfs_write fs/read_write.c:594 ksys_write fs/read_write.c:648 do_syscall_64 arch/x86/entry/common.c:50 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113 Add error check in devm_regmap_init_encx24j600 to avoid this situation. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: encx24j600: error de verificación en devm_regmap_init_encx24j600 devm_regmap_init puede devolver un error causado por falta de memoria, esto resultará en una desreferencia del puntero nulo más adelante al leer o escribir el registro: falla de protección general en encx24j600_spi_probe KASAN: null-ptr-deref en el rango [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 286 Comm: spi-encx24j600- No contaminado 5.15.0-rc2-00142-g9978db7 50e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652 Nombre del hardware: PC estándar QEMU ( i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540 Código: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00 RSP: 0018:ffffc900010476b8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 00000000000000000 RDX: 0000000000000012 RSI: 888002de0000 RDI: 0000000000000094 RBP: ffff888013c9a000 R08: 0000000000000000 R09: ffffbfff3f9cc6a R10: ffffc900010476e8 R11: ffffbfff3f9cc69 : 0000000000000001 R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08 FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000 CS: 010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 00000 00000000000DR2 : 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459 spi_probe drivers/spi/spi.c:397 Actually_probe drivers/base/dd.c:517 __driver_probe_device drivers/base/dd.c:751 driver_probe_device drivers/ base/dd.c:782 __device_attach_driver drivers/base/dd.c:899 bus_for_each_drv drivers/base/bus.c:427 __device_attach drivers/base/dd.c:971 bus_probe_device drivers/base/bus.c:487 device_add drivers/ base/core.c:3364 __spi_add_device drivers/spi/spi.c:599 spi_add_device drivers/spi/spi.c:641 spi_new_device drivers/spi/spi.c:717 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d0 0630982840568e85e] controladores/base dev_attr_store /core.c:2074 sysfs_kf_write fs/sysfs/file.c:139 kernfs_fop_write_iter fs/kernfs/file.c:300 new_sync_write fs/read_write.c:508 (discriminador 4) vfs_write fs/read_write.c:594 ksys_write fs/read_write .c:648 do_syscall_64 arch/x86/entry/common.c:50 Entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113 Agregue verificación de errores en devm_regmap_init_encx24j600 para evitar esta situación. • https://git.kernel.org/stable/c/04fbfce7a222327b97ca165294ef19f0faa45960 https://git.kernel.org/stable/c/66358471fa75a713fd76bc8a4bd74cb14cd50a4f https://git.kernel.org/stable/c/f043fac1133a6c5ef960a8422c0f6dd711dee462 https://git.kernel.org/stable/c/fddc7f678d7fb93caa0d7bc512f968ff1e2bddbc https://git.kernel.org/stable/c/5e5494e6fc8a29c927e0478bec4a078a40da8901 https://git.kernel.org/stable/c/4c2eb80fc90b05559ce6ed1b8dfb2348420b5644 https://git.kernel.org/stable/c/e19c10d6e07c59c96e90fe053a72683ad8b0397e https://git.kernel.org/stable/c/322c0e53496309e634d9db7349678eaad • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47439 – net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work
https://notcve.org/view.php?id=CVE-2021-47439
In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work When the ksz module is installed and removed using rmmod, kernel crashes with null pointer dereferrence error. During rmmod, ksz_switch_remove function tries to cancel the mib_read_workqueue using cancel_delayed_work_sync routine and unregister switch from dsa. During dsa_unregister_switch it calls ksz_mac_link_down, which in turn reschedules the workqueue since mib_interval is non-zero. Due to which queue executed after mib_interval and it tries to access dp->slave. But the slave is unregistered in the ksz_switch_remove function. Hence kernel crashes. To avoid this crash, before canceling the workqueue, resetted the mib_interval to 0. v1 -> v2: -Removed the if condition in ksz_mib_read_work En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: dsa: microchip: se agregó la condición para programar ksz_mib_read_work Cuando el módulo ksz se instala y elimina usando rmmod, el kernel falla con un error de desreferencia de puntero nulo. Durante rmmod, la función ksz_switch_remove intenta cancelar mib_read_workqueue usando la rutina cancel_delayed_work_sync y cancelar el registro del conmutador de dsa. • https://git.kernel.org/stable/c/469b390e1ba330e888175e55d78573db2e9a8cb4 https://git.kernel.org/stable/c/f2e1de075018cf71bcd7d628e9f759cb8540b0c3 https://git.kernel.org/stable/c/383239a33cf29ebee9ce0d4e0e5c900b77a16148 https://git.kernel.org/stable/c/ef1100ef20f29aec4e62abeccdb5bdbebba1e378 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47438 – net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path
https://notcve.org/view.php?id=CVE-2021-47438
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path Prior to this patch in case mlx5_core_destroy_cq() failed it returns without completing all destroy operations and that leads to memory leak. Instead, complete the destroy flow before return error. Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq() to be symmetrical with mlx5_core_create_cq(). kmemleak complains on: unreferenced object 0xc000000038625100 (size 64): comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s) hex dump (first 32 bytes): 60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4..... 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}..... backtrace: [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core] [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core] [<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core] [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core] [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core] [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core] [<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core] [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230 [mlx5_core] [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300 [mlx5_core] [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core] [<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core] [<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0 [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0 [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0 [<00000000646c5c2c>] genl_rcv_msg+0x78/0x120 [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: corrige la pérdida de memoria en la ruta de error mlx5_core_destroy_cq(). Antes de este parche, en caso de que mlx5_core_destroy_cq() fallara, regresa sin completar todas las operaciones de destrucción y eso conduce a una pérdida de memoria. En su lugar, complete el flujo de destrucción antes de que se produzca el error de devolución. También mueva mlx5_debug_cq_remove() al principio de mlx5_core_destroy_cq() para que sea simétrico con mlx5_core_create_cq(). kmemleak se queja de: objeto sin referencia 0xc000000038625100 (tamaño 64): comm "ethtool", pid 28301, jiffies 4298062946 (edad 785.380 s) volcado hexadecimal (primeros 32 bytes): 60 01 48 94 00 00 00 c0 b8 05 34 3 00 00 00 c0 `.H.......4..... 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}..... rastreo hacia atrás : [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core] [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core] [<000000002a12918f>] 0x1d0/0x2d0 [mlx5_core] [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core] [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core] [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core] [<0000000081839561>] 5e_open_channels+0x9cc/0x13e0 [mlx5_core] [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4 /0x230 [mlx5_core] [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300 [mlx5_core] [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core [<00000000a] 0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core] [<00000000a8f3d84b>] etnl_set_privflags +0x234/0x2d0 [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0 [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0 [<00000000646c5c2c>] v_msg+0x78/0x120 [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0 • https://git.kernel.org/stable/c/e126ba97dba9edeb6fafa3665b5f8497fc9cdf8c https://git.kernel.org/stable/c/4f7bddf8c5c01cac74373443b13a68e1c6723a94 https://git.kernel.org/stable/c/ed8aafea4fec9c654e63445236e0b505e27ed3a7 https://git.kernel.org/stable/c/94b960b9deffc02fc0747afc01f72cc62ab099e3 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47436 – usb: musb: dsps: Fix the probe error path
https://notcve.org/view.php?id=CVE-2021-47436
In the Linux kernel, the following vulnerability has been resolved: usb: musb: dsps: Fix the probe error path Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb") has inverted the calls to dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without updating correctly the error path. dsps_create_musb_pdev() allocates and registers a new platform device which must be unregistered and freed with platform_device_unregister(), and this is missing upon dsps_setup_optional_vbus_irq() error. While on the master branch it seems not to trigger any issue, I observed a kernel crash because of a NULL pointer dereference with a v5.10.70 stable kernel where the patch mentioned above was backported. With this kernel version, -EPROBE_DEFER is returned the first time dsps_setup_optional_vbus_irq() is called which triggers the probe to error out without unregistering the platform device. Unfortunately, on the Beagle Bone Black Wireless, the platform device still living in the system is being used by the USB Ethernet gadget driver, which during the boot phase triggers the crash. My limited knowledge of the musb world prevents me to revert this commit which was sent to silence a robot warning which, as far as I understand, does not make sense. The goal of this patch was to prevent an IRQ to fire before the platform device being registered. I think this cannot ever happen due to the fact that enabling the interrupts is done by the ->enable() callback of the platform musb device, and this platform device must be already registered in order for the core or any other user to use this callback. Hence, I decided to fix the error path, which might prevent future errors on mainline kernels while also fixing older ones. • https://git.kernel.org/stable/c/5269937d1483d3159d5b51907346e4f4b13ef079 https://git.kernel.org/stable/c/ffc825049ed2e8c849d318e987fd5073e0be462f https://git.kernel.org/stable/c/9a4a6805294fa7d2653e82972bdaf9e3e1f3d3c9 https://git.kernel.org/stable/c/8de01a896c1bc14b6b65b8d26013626597a45eda https://git.kernel.org/stable/c/72bb3eafcfdd156713a3ea0c9c95d536bd6e6e55 https://git.kernel.org/stable/c/f5b4df24b4209cc3b9ccc768897415be18807e46 https://git.kernel.org/stable/c/5ed60a430fb5f3d93e7fef66264daef466b4d10c https://git.kernel.org/stable/c/e923bce31ffefe4f60edfc6b84f62d4a8 •