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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47206 – usb: host: ohci-tmio: check return value after calling platform_get_resource()
https://notcve.org/view.php?id=CVE-2021-47206
In the Linux kernel, the following vulnerability has been resolved: usb: host: ohci-tmio: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. • https://git.kernel.org/stable/c/28e016e02118917e50a667bc72fb80098cf2b460 https://git.kernel.org/stable/c/2f18f97a1a787154a372c0738f1576f14b693d91 https://git.kernel.org/stable/c/bb6ed2e05eb6e8619b30fa854f9becd50c11723f https://git.kernel.org/stable/c/951b8239fd24678b56c995c5c0456ab12e059d19 https://git.kernel.org/stable/c/f98986b7acb4219f95789095eced93ed69d81d35 https://git.kernel.org/stable/c/2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100 https://git.kernel.org/stable/c/065334f6640d074a1caec2f8b0091467a22f9483 https://git.kernel.org/stable/c/9eff2b2e59fda25051ab36cd1cb501466 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47205 – clk: sunxi-ng: Unregister clocks/resets when unbinding
https://notcve.org/view.php?id=CVE-2021-47205
In the Linux kernel, the following vulnerability has been resolved: clk: sunxi-ng: Unregister clocks/resets when unbinding Currently, unbinding a CCU driver unmaps the device's MMIO region, while leaving its clocks/resets and their providers registered. This can cause a page fault later when some clock operation tries to perform MMIO. Fix this by separating the CCU initialization from the memory allocation, and then using a devres callback to unregister the clocks and resets. This also fixes a memory leak of the `struct ccu_reset`, and uses the correct owner (the specific platform driver) for the clocks and resets. Early OF clock providers are never unregistered, and limited error handling is possible, so they are mostly unchanged. The error reporting is made more consistent by moving the message inside of_sunxi_ccu_probe. • https://git.kernel.org/stable/c/b5dd513daa70ee8f6d281a20bd28485ee9bb7db2 https://git.kernel.org/stable/c/9bec2b9c6134052994115d2d3374e96f2ccb9b9d •