CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47212 – net/mlx5: Update error handler for UCTX and UMEM
https://notcve.org/view.php?id=CVE-2021-47212
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Update error handler for UCTX and UMEM In the fast unload flow, the device state is set to internal error, which indicates that the driver started the destroy process. In this case, when a destroy command is being executed, it should return MLX5_CMD_STAT_OK. Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK instead of EIO. This fixes a call trace in the umem release process - [ 2633.536695] Call Trace: [ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] [ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core] [ 2633.539641] disable_device+0x8c/0x130 [ib_core] [ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core] [ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core] [ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib] [ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary] [ 2633.544661] device_release_driver_internal+0x103/0x1f0 [ 2633.545679] bus_remove_device+0xf7/0x170 [ 2633.546640] device_del+0x181/0x410 [ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core] [ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core] [ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core] [ 2633.550864] remove_one+0x69/0xe0 [mlx5_core] [ 2633.551819] pci_device_remove+0x3b/0xc0 [ 2633.552731] device_release_driver_internal+0x103/0x1f0 [ 2633.553746] unbind_store+0xf6/0x130 [ 2633.554657] kernfs_fop_write+0x116/0x190 [ 2633.555567] vfs_write+0xa5/0x1a0 [ 2633.556407] ksys_write+0x4f/0xb0 [ 2633.557233] do_syscall_64+0x5b/0x1a0 [ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 2633.559018] RIP: 0033:0x7f9977132648 [ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55 [ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648 [ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001 [ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740 [ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0 [ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c [ 2633.568725] ---[ end trace 10b4fe52945e544d ]--- • https://git.kernel.org/stable/c/6a6fabbfa3e8c656ff906ae999fb6856410fa4cd https://git.kernel.org/stable/c/a51a6da375d82aed5c8f83abd13e7d060421bd48 https://git.kernel.org/stable/c/ba50cd9451f6c49cf0841c0a4a146ff6a2822699 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47211 – ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
https://notcve.org/view.php?id=CVE-2021-47211
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix null pointer dereference on pointer cs_desc The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference. • https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739 https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47210 – usb: typec: tipd: Remove WARN_ON in tps6598x_block_read
https://notcve.org/view.php?id=CVE-2021-47210
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Remove WARN_ON in tps6598x_block_read Calling tps6598x_block_read with a higher than allowed len can be handled by just returning an error. There's no need to crash systems with panic-on-warn enabled. • https://git.kernel.org/stable/c/2a897d384513ba7f7ef05611338b9a6ec6aeac00 https://git.kernel.org/stable/c/30dcfcda8992dc42f18e7d35b6a1fa72372d382d https://git.kernel.org/stable/c/eff8b7628410cb2eb562ca0d5d1f12e27063733e https://git.kernel.org/stable/c/2c71811c963b6c310a29455d521d31a7ea6c5b5e https://git.kernel.org/stable/c/b7a0a63f3fed57d413bb857de164ea9c3984bc4e •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47209 – sched/fair: Prevent dead task groups from regaining cfs_rq's
https://notcve.org/view.php?id=CVE-2021-47209
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Prevent dead task groups from regaining cfs_rq's Kevin is reporting crashes which point to a use-after-free of a cfs_rq in update_blocked_averages(). Initial debugging revealed that we've live cfs_rq's (on_list=1) in an about to be kfree()'d task group in free_fair_sched_group(). However, it was unclear how that can happen. His kernel config happened to lead to a layout of struct sched_entity that put the 'my_q' member directly into the middle of the object which makes it incidentally overlap with SLUB's freelist pointer. That, in combination with SLAB_FREELIST_HARDENED's freelist pointer mangling, leads to a reliable access violation in form of a #GP which made the UAF fail fast. Michal seems to have run into the same issue[1]. He already correctly diagnosed that commit a7b359fc6a37 ("sched/fair: Correctly insert cfs_rq's to list on unthrottle") is causing the preconditions for the UAF to happen by re-adding cfs_rq's also to task groups that have no more running tasks, i.e. also to dead ones. His analysis, however, misses the real root cause and it cannot be seen from the crash backtrace only, as the real offender is tg_unthrottle_up() getting called via sched_cfs_period_timer() via the timer interrupt at an inconvenient time. When unregister_fair_sched_group() unlinks all cfs_rq's from the dying task group, it doesn't protect itself from getting interrupted. • https://git.kernel.org/stable/c/a7b359fc6a37faaf472125867c8dc5a068c90982 https://git.kernel.org/stable/c/512e21c150c1c3ee298852660f3a796e267e62ec https://git.kernel.org/stable/c/b027789e5e50494c2325cc70c8642e7fd6059479 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47207 – ALSA: gus: fix null pointer dereference on pointer block
https://notcve.org/view.php?id=CVE-2021-47207
In the Linux kernel, the following vulnerability has been resolved: ALSA: gus: fix null pointer dereference on pointer block The pointer block return from snd_gf1_dma_next_block could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference. • https://git.kernel.org/stable/c/3e28e083dcdf03a18a083f8a47b6bb6b1604b5be https://git.kernel.org/stable/c/cb09c760c201f82df83babc92a5ffea0a01807fc https://git.kernel.org/stable/c/542fa721594a02d2aee0370a764d306ef48d030c https://git.kernel.org/stable/c/ab4c1ebc40f699f48346f634d7b72b9c5193f315 https://git.kernel.org/stable/c/c6d2cefdd05c4810c416fb8d384b5c377bd977bc https://git.kernel.org/stable/c/1ac6cd87d8ddd36c43620f82c4d65b058f725f0f https://git.kernel.org/stable/c/16721797dcef2c7c030ffe73a07f39a65f9323c3 https://git.kernel.org/stable/c/a0d21bb3279476c777434c40d969ea88c •