CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47039 – ataflop: potential out of bounds in do_format()
https://notcve.org/view.php?id=CVE-2021-47039
In the Linux kernel, the following vulnerability has been resolved: ataflop: potential out of bounds in do_format() The function uses "type" as an array index: q = unit[drive].disk[type]->queue; Unfortunately the bounds check on "type" isn't done until later in the function. Fix this by moving the bounds check to the start. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ataflop: potencial fuera de los límites en do_format() La función utiliza "tipo" como índice de matriz: q = unidad[unidad].disco[tipo]->cola; Desafortunadamente, la verificación de los límites en "tipo" no se realiza hasta más adelante en la función. Solucione este problema moviendo la verificación de los límites al inicio. • https://git.kernel.org/stable/c/bf9c0538e485b591a2ee02d9adb8a99db4be5a2a https://git.kernel.org/stable/c/07f86aa8f4fe077be1b018cc177eb8c6573e5671 https://git.kernel.org/stable/c/2a3a8bbca28b899806844c00d49ed1b7ccb50957 https://git.kernel.org/stable/c/1ffec389a6431782a8a28805830b6fae9bf00af1 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47038 – Bluetooth: avoid deadlock between hci_dev->lock and socket lock
https://notcve.org/view.php?id=CVE-2021-47038
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: avoid deadlock between hci_dev->lock and socket lock Commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option") added a dependency between socket lock and hci_dev->lock that could lead to deadlock. It turns out that hci_conn_get_phy() is not in any way relying on hdev being immutable during the runtime of this function, neither does it even look at any of the members of hdev, and as such there is no need to hold that lock. This fixes the lockdep splat below: ====================================================== WARNING: possible circular locking dependency detected 5.12.0-rc1-00026-g73d464503354 #10 Not tainted ------------------------------------------------------ bluetoothd/1118 is trying to acquire lock: ffff8f078383c078 (&hdev->lock){+.+.}-{3:3}, at: hci_conn_get_phy+0x1c/0x150 [bluetooth] but task is already holding lock: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}: lock_sock_nested+0x72/0xa0 l2cap_sock_ready_cb+0x18/0x70 [bluetooth] l2cap_config_rsp+0x27a/0x520 [bluetooth] l2cap_sig_channel+0x658/0x1330 [bluetooth] l2cap_recv_frame+0x1ba/0x310 [bluetooth] hci_rx_work+0x1cc/0x640 [bluetooth] process_one_work+0x244/0x5f0 worker_thread+0x3c/0x380 kthread+0x13e/0x160 ret_from_fork+0x22/0x30 -> #2 (&chan->lock#2/1){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x33a/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (&conn->chan_lock){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x322/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&hdev->lock){+.+.}-{3:3}: __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 __mutex_lock+0xa3/0xa10 hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc/0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &hdev->lock --> &chan->lock#2/1 --> sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&chan->lock#2/1); lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&hdev->lock); *** DEADLOCK *** 1 lock held by bluetoothd/1118: #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth] stack backtrace: CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 Call Trace: dump_stack+0x7f/0xa1 check_noncircular+0x105/0x120 ? __lock_acquire+0x147a/0x1a50 __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? __lock_acquire+0x2e1/0x1a50 ? lock_is_held_type+0xb4/0x120 ? • https://git.kernel.org/stable/c/eab2404ba798a8efda2a970f44071c3406d94e57 https://git.kernel.org/stable/c/7cc0ba67883c6c8d3bddb283f56c167fc837a555 https://git.kernel.org/stable/c/fee71f480bc1dec5f6ae3b0b185ff12a62bceabc https://git.kernel.org/stable/c/332e69eb3bd90370f2d9f2c2ca7974ff523dea17 https://git.kernel.org/stable/c/17486960d79b900c45e0bb8fbcac0262848582ba •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47037 – ASoC: q6afe-clocks: fix reprobing of the driver
https://notcve.org/view.php?id=CVE-2021-47037
In the Linux kernel, the following vulnerability has been resolved: ASoC: q6afe-clocks: fix reprobing of the driver Q6afe-clocks driver can get reprobed. For example if the APR services are restarted after the firmware crash. However currently Q6afe-clocks driver will oops because hw.init will get cleared during first _probe call. Rewrite the driver to fill the clock data at runtime rather than using big static array of clocks. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: q6afe-clocks: corrección de reprobación del controlador El controlador Q6afe-clocks puede ser reprobado. • https://git.kernel.org/stable/c/520a1c396d1966b64884d8e0176a580150d5a09e https://git.kernel.org/stable/c/6893df3753beafa5f7351228a9dd8157a57d7492 https://git.kernel.org/stable/c/62413972f5266568848a36fd15160397b211fa74 https://git.kernel.org/stable/c/96fadf7e8ff49fdb74754801228942b67c3eeebd •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47036 – udp: skip L4 aggregation for UDP tunnel packets
https://notcve.org/view.php?id=CVE-2021-47036
In the Linux kernel, the following vulnerability has been resolved: udp: skip L4 aggregation for UDP tunnel packets If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there are UDP tunnels available in the system, udp_gro_receive() could end-up doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at the outer UDP tunnel level for packets effectively carrying and UDP tunnel header. That could cause inner protocol corruption. If e.g. the relevant packets carry a vxlan header, different vxlan ids will be ignored/ aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc. Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the current packet could land in a UDP tunnel, and let udp_gro_receive() do GRO via udp_sk(sk)->gro_receive. The check implemented in this patch is broader than what is strictly needed, as the existing UDP tunnel could be e.g. configured on top of a different device: we could end-up skipping GRO at-all for some packets. Anyhow, that is a very thin corner case and covering it will add quite a bit of complexity. v1 -> v2: - hopefully clarify the commit message En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: omitir la agregación L4 para paquetes de túnel UDP Si NETIF_F_GRO_FRAGLIST o NETIF_F_GRO_UDP_FWD están habilitados y hay túneles UDP disponibles en el sistema, udp_gro_receive() podría terminar realizando la agregación L4 (ya sea SKB_GSO_UDP_L4 o SKB_GSO_FRAGLIST) en el nivel del túnel UDP externo para paquetes que transportan efectivamente un encabezado de túnel UDP. Eso podría causar corrupción del protocolo interno. • https://git.kernel.org/stable/c/9fd1ff5d2ac7181844735806b0a703c942365291 https://git.kernel.org/stable/c/450687386cd16d081b58cd7a342acff370a96078 https://git.kernel.org/stable/c/18f25dc399901426dff61e676ba603ff52c666f7 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47035 – iommu/vt-d: Remove WO permissions on second-level paging entries
https://notcve.org/view.php?id=CVE-2021-47035
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove WO permissions on second-level paging entries When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration. • https://git.kernel.org/stable/c/b802d070a52a1565b47daaa808872cfbd4a17b01 https://git.kernel.org/stable/c/c848416cc05afc1589edba04fe00b85c2f797ee3 https://git.kernel.org/stable/c/89bd620798704a8805fc9db0d71d7f812cf5b3d2 https://git.kernel.org/stable/c/25faff78138933244c678c7fc78f7c0340fa04a0 https://git.kernel.org/stable/c/66c24699f266ff310381a9552d3576eea8ad6e20 https://git.kernel.org/stable/c/eea53c5816889ee8b64544fa2e9311a81184ff9c •