CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47275 – bcache: avoid oversized read request in cache missing code path
https://notcve.org/view.php?id=CVE-2021-47275
In the Linux kernel, the following vulnerability has been resolved: bcache: avoid oversized read request in cache missing code path In the cache missing code path of cached device, if a proper location from the internal B+ tree is matched for a cache miss range, function cached_dev_cache_miss() will be called in cache_lookup_fn() in the following code block, [code block 1] 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode 527 ? ... Then the 0- sized s->iop.replace_key is inserted into the internal B+ tree as cache missing check key (a special key to detect and avoid a racing between normal write request and cache missing read request) as, [code block 8] 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key); Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey size check BUG_ON() in code block 2, and causes the kernel panic 1). Another ke ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: evita solicitudes de lectura de gran tamaño en la ruta del código faltante de la caché. • https://git.kernel.org/stable/c/555002a840ab88468e252b0eedf0b05e2ce7099c https://git.kernel.org/stable/c/41fe8d088e96472f63164e213de44ec77be69478 •
CVSS: 9.8EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47274 – tracing: Correct the length check which causes memory corruption
https://notcve.org/view.php?id=CVE-2021-47274
In the Linux kernel, the following vulnerability has been resolved: tracing: Correct the length check which causes memory corruption We've suffered from severe kernel crashes due to memory corruption on our production environment, like, Call Trace: [1640542.554277] general protection fault: 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286 [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09: 0000000000000000 [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) knlGS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Call Trace: [1640542.567009] anon_vma_clone+0x5d/0x170 [1640542.567417] __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] do_syscall_64+0x5b/0x1b0 [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang has reproduced it stably on the latest 4.19 LTS. After some debugging, we finally proved that it's due to ftrace buffer out-of-bound access using a debug tool as follows: [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000 [ 86.780806] no_context+0xdf/0x3c0 [ 86.784327] __do_page_fault+0x252/0x470 [ 86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] fetch_memory_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func+0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] 0xffffffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [ 86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 ("tracing: Check length before giving out the filter buffer") adds length check to protect trace data overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent overflow entirely, the length check should also take the sizeof entry->array[0] into account, since this array[0] is filled the length of trace data and occupy addtional space and risk overflow. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rastreo: corrija la verificación de longitud que causa corrupción de la memoria. • https://git.kernel.org/stable/c/2e584b1a02eeb860e286d39bc408b25ebc5ec844 https://git.kernel.org/stable/c/e46d433754420b4d6513ca389403de88a0910279 https://git.kernel.org/stable/c/0572fc6a510add9029b113239eaabf4b5bce8ec9 https://git.kernel.org/stable/c/a0997a86f5c0085e183ddee5fb72091d584d3d16 https://git.kernel.org/stable/c/7c93d8cff582c459350d6f8906eea6e4cd60d959 https://git.kernel.org/stable/c/b220c049d5196dd94d992dd2dc8cba1a5e6123bf https://git.kernel.org/stable/c/edcce01e0e50840a9aa6a70baed21477bdd2c9f9 https://git.kernel.org/stable/c/2d598902799886d67947406f26ee8e5fd • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47273 – usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled
https://notcve.org/view.php?id=CVE-2021-47273
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled When only PHY1 is used (for example on Odroid-HC4), the regmap init code uses the usb2 ports when doesn't initialize the PHY1 regmap entry. This fixes: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... pc : regmap_update_bits_base+0x40/0xa0 lr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8 ... Call trace: regmap_update_bits_base+0x40/0xa0 dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8 dwc3_meson_g12a_usb2_init+0x7c/0xc8 dwc3_meson_g12a_usb_init+0x28/0x48 dwc3_meson_g12a_probe+0x298/0x540 platform_probe+0x70/0xe0 really_probe+0xf0/0x4d8 driver_probe_device+0xfc/0x168 ... En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3-meson-g12a: repara el init de glue PHY de usb2 cuando phy0 está deshabilitado. • https://git.kernel.org/stable/c/013af227f58a97ffc61b99301f8f4448dc7e7f55 https://git.kernel.org/stable/c/750a0d75564293be3ed50f13ef7f38ab75106421 https://git.kernel.org/stable/c/d8dd3754e707104a34f8ec595034d503ea8871a2 https://git.kernel.org/stable/c/4d2aa178d2ad2fb156711113790dde13e9aa2376 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47272 – usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL
https://notcve.org/view.php?id=CVE-2021-47272
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL There exists a possible scenario in which dwc3_gadget_init() can fail: during during host -> peripheral mode switch in dwc3_set_mode(), and a pending gadget driver fails to bind. ... En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: Bail from dwc3_gadget_exit() si dwc->gadget es NULL. • https://git.kernel.org/stable/c/e81a7018d93a7de31a3f121c9a7eecd0a5ec58b0 https://git.kernel.org/stable/c/851dee5a5da56564a70290713aee665403bb0b24 https://git.kernel.org/stable/c/4aad390363d2b9b3e92428dd34d27bb7ea8f1ee8 https://git.kernel.org/stable/c/03715ea2e3dbbc56947137ce3b4ac18a726b2f87 •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47271 – usb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler
https://notcve.org/view.php?id=CVE-2021-47271
In the Linux kernel, the following vulnerability has been resolved: usb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler Patch fixes the following critical issue caused by deadlock which has been detected during testing NCM class: smp: csd: Detected non-responsive CSD lock (#1) on CPU#0 smp: csd: CSD lock (#1) unresponsive. .... RIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0 RSP: 0018:ffffbc494011cde0 EFLAGS: 00000002 RAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658 RBP: ffffbc494011cde0 R08: 0000000000000001 R09: 0000000000000000 R10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658 R13: ffff9ee8116b4670 R14: 0000000000000246 R15: ffff9ee8116b4658 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0 Call Trace: <IRQ> do_raw_spin_lock+0xc0/0xd0 _raw_spin_lock_irqsave+0x95/0xa0 cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci] usb_ep_queue+0x35/0x110 eth_start_xmit+0x220/0x3d0 [u_ether] ncm_tx_timeout+0x34/0x40 [usb_f_ncm] ? ... En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdnsp: soluciona el problema de interbloqueo en cdnsp_thread_irq_handler. • https://git.kernel.org/stable/c/3d82904559f4f5a2622db1b21de3edf2eded7664 https://git.kernel.org/stable/c/ae746b6f4ce619cf4032fd798a232b010907a397 https://git.kernel.org/stable/c/a9aecef198faae3240921b707bc09b602e966fce •