CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2020-36777 – media: dvbdev: Fix memory leak in dvb_media_device_free()
https://notcve.org/view.php?id=CVE-2020-36777
In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: Fix memory leak in dvb_media_device_free() dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn` before setting it to NULL, as documented in include/media/media-device.h: "The media_entity instance itself must be freed explicitly by the driver if required." En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: dvbdev: corrige la pérdida de memoria en dvb_media_device_free() dvb_media_device_free() está perdiendo memoria. Libere `dvbdev->adapter->conn` antes de configurarlo en NULL, como se documenta en include/media/media-device.h: "La instancia media_entity debe ser liberada explícitamente por el controlador si es necesario". A flaw was found in the Linux kernel. • https://git.kernel.org/stable/c/0230d60e4661d9ced6fb0b9a30f182ebdafbba7a https://git.kernel.org/stable/c/06854b943e0571ccbd7ad0a529babed1a98ff275 https://git.kernel.org/stable/c/32168ca1f123316848fffb85d059860adf3c409f https://git.kernel.org/stable/c/cd89f79be5d553c78202f686e8e4caa5fbe94e98 https://git.kernel.org/stable/c/9185b3b1c143b8da409c19ac5a785aa18d67a81b https://git.kernel.org/stable/c/43263fd43083e412311fa764cd04a727b0c6a749 https://git.kernel.org/stable/c/9ad15e214fcd73694ea51967d86055f47b802066 https://git.kernel.org/stable/c/cede24d13be6c2a62be6d7ceea63c2719 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2021-46936 – net: fix use-after-free in tw_timer_handler
https://notcve.org/view.php?id=CVE-2021-46936
In the Linux kernel, the following vulnerability has been resolved: net: fix use-after-free in tw_timer_handler A real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Call Trace: <IRQ> call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 This issue was also reported since 2017 in the thread [1], unfortunately, the issue was still can be reproduced after fixing DCCP. The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some inflight time-wait timers. This bug is not introduced by commit f2bf415cfed7 ("mib: add net to NET_ADD_STATS_BH") since the net_statistics is a global variable instead of dynamic allocation and freeing. Actually, commit 61a7e26028b9 ("mib: put net statistics on struct net") introduces the bug since it put net statistics on struct net and free it when net namespace is destroyed. Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is meaningless when init_ipv4_mibs() fails. [1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: corrige use-after-free en tw_timer_handler Se encontró un problema de pánico en el mundo real como se muestra a continuación en Linux 5.4. ERROR: no se puede manejar el error de página para la dirección: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Seguimiento de llamadas: call_timer_fn+0x2b/ 0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/ 0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 Este problema también se informó desde 2017 en el hilo [1], desafortunadamente, el problema aún se puede reproducir después de corregir DCCP. ipv4_mib_exit_net se llama antes de tcp_sk_exit_batch cuando se destruye un espacio de nombres de red, ya que tcp_sk_ops está registrado antes de ipv4_mib_ops, lo que significa que tcp_sk_ops está al frente de ipv4_mib_ops en la lista de pernet_list. • https://git.kernel.org/stable/c/61a7e26028b94805fd686a6dc9dbd9941f8f19b0 https://git.kernel.org/stable/c/15579e1301f856ad9385d720c9267c11032a5022 https://git.kernel.org/stable/c/e73164e89d1be561228a4534e1091369ee4ba41a https://git.kernel.org/stable/c/5c2fe20ad37ff56070ae0acb34152333976929b4 https://git.kernel.org/stable/c/a8e1944b44f94f5c5f530e434c5eaee787254566 https://git.kernel.org/stable/c/fe5838c22b986c1190f1dce9aa09bf6a491c1a69 https://git.kernel.org/stable/c/2386e81a1d277f540e1285565c9d41d531bb69d4 https://git.kernel.org/stable/c/08eacbd141e2495d2fcdde84358a06c4f • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-46933 – usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.
https://notcve.org/view.php?id=CVE-2021-46933
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear. ffs_data_clear is indirectly called from both ffs_fs_kill_sb and ffs_ep0_release, so it ends up being called twice when userland closes ep0 and then unmounts f_fs. If userland provided an eventfd along with function's USB descriptors, it ends up calling eventfd_ctx_put as many times, causing a refcount underflow. NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls. Also, set epfiles to NULL right after de-allocating it, for readability. For completeness, ffs_data_clear actually ends up being called thrice, the last call being before the whole ffs structure gets freed, so when this specific sequence happens there is a second underflow happening (but not being reported): /sys/kernel/debug/tracing# modprobe usb_f_fs /sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter /sys/kernel/debug/tracing# echo function > current_tracer /sys/kernel/debug/tracing# echo 1 > tracing_on (setup gadget, run and kill function userland process, teardown gadget) /sys/kernel/debug/tracing# echo 0 > tracing_on /sys/kernel/debug/tracing# cat trace smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] ..... 1946.279147: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] .n... 1946.905512: ffs_data_clear <-ffs_data_put Warning output corresponding to above trace: [ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c [ 1946.293094] refcount_t: underflow; use-after-free. [ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E) [ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G C OE 5.15.0-1-rpi #1 Debian 5.15.3-1 [ 1946.417950] Hardware name: BCM2835 [ 1946.425442] Backtrace: [ 1946.432048] [<c08d60a0>] (dump_backtrace) from [<c08d62ec>] (show_stack+0x20/0x24) [ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c [ 1946.458412] [<c08d62cc>] (show_stack) from [<c08d9ae0>] (dump_stack+0x28/0x30) [ 1946.470380] [<c08d9ab8>] (dump_stack) from [<c0123500>] (__warn+0xe8/0x154) [ 1946.482067] r5:c04a948c r4:c0a71dc8 [ 1946.490184] [<c0123418>] (__warn) from [<c08d6948>] (warn_slowpath_fmt+0xa0/0xe4) [ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04 [ 1946.517070] [<c08d68ac>] (warn_slowpath_fmt) from [<c04a948c>] (refcount_warn_saturate+0x110/0x15c) [ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0 [ 1946.546708] [<c04a937c>] (refcount_warn_saturate) from [<c0380134>] (eventfd_ctx_put+0x48/0x74) [ 1946.564476] [<c03800ec>] (eventfd_ctx_put) from [<bf5464e8>] (ffs_data_clear+0xd0/0x118 [usb_f_fs]) [ 1946.582664] r5:c3b84c00 r4:c2695b00 [ 1946.590668] [<bf546418>] (ffs_data_clear [usb_f_fs]) from [<bf547cc0>] (ffs_data_closed+0x9c/0x150 [usb_f_fs]) [ 1946.609608] r5:bf54d014 r4:c2695b00 [ 1946.617522] [<bf547c24>] (ffs_data_closed [usb_f_fs]) from [<bf547da0>] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs]) [ 1946.636217] r7:c0dfcb ---truncated--- En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_fs: Borrar ffs_eventfd en ffs_data_clear. ffs_data_clear se llama indirectamente desde ffs_fs_kill_sb y ffs_ep0_release, por lo que termina siendo llamado dos veces cuando el área de usuario cierra ep0 y luego desmonta f_fs. Si Userland proporcionó un eventfd junto con los descriptores USB de la función, termina llamando a eventfd_ctx_put tantas veces, provocando un desbordamiento insuficiente de recuento. NULL-ify ffs_eventfd para evitar estas llamadas extrañas eventfd_ctx_put. Además, establezca epfiles en NULL justo después de desasignarlo, para facilitar la lectura. Para completar, ffs_data_clear en realidad termina siendo llamado tres veces, la última llamada es antes de que se libere toda la estructura de ffs, por lo que cuando ocurre esta secuencia específica, se produce un segundo desbordamiento insuficiente (pero no se informa): /sys/kernel/debug/tracing # modprobe usb_f_fs /sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter /sys/kernel/debug/tracing# echo function > current_tracer /sys/kernel/debug/tracing# echo 1 > tracing_on (dispositivo de configuración, función ejecutar y finalizar proceso de usuario, dispositivo de desmontaje) /sys/kernel/debug/tracing# echo 0 > tracing_on /sys/kernel/debug/tracing# cat trace smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear <-ffs_data_closed tarjeta inteligente -openp-431 [000] ..... 1946.279147: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] .n... 1946.905512: ffs_data_clear <-ffs_data_put Salida de advertencia correspondiente al seguimiento anterior: [ 1946.284139] ADVERTENCIA: CPU : 0 PID: 431 en lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c [ 1946.293094] refcount_t: desbordamiento insuficiente; use-after-free. [1946.298164] Módulos vinculados en: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E ) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_b cm2835 (CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E ) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c (E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E ) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E) [ 1946.399633] CPU: 0 PID: 431 Comm: tarjeta inteligente- openp Contaminado: GC OE 5.15.0-1-rpi #1 Debian 5.15.3-1 [ 1946.417950] Nombre de hardware: BCM2835 [ 1946.425442] Seguimiento inverso: [ 1946.432048] [] (dump_backtrace) de [] ( show_stack+0x20/0x24) [ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c [ 1946.458412] [] (show_stack) de [] (dump_ pila+0x28/0x30) [ 1946.470380] [< c08d9ab8>] (dump_stack) de [] (__warn+0xe8/0x154) [ 1946.482067] r5:c04a948c r4:c0a71dc8 [ 1946.490184] [] (__warn) de [] (warn_slowpath_fmt+0xa0/ 0xe4) [ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04 [ 1946.517070] [] (warn_slowpath_fmt) de [] (refcount_war n_saturado+0x110/0x15c) [ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0 [ 1946.546708] [] (refcount_warn_saturate) de [] (eventfd_ctx_put+0x48/0x74) [ 1946.564476] [] (eventfd_ctx_put) de [] (ffs_data_clear+0xd0/0x118 [usb_f_fs]) [ 1946.582664] r5:c3b84c00 r4:c2695b00 [ 1946.590668] [] (ffs_data_clear [usb_f_fs]) de [] ( ffs_data_closed+0x9c/0x150 [usb_f_fs]) [ 1946.609608] r5:bf54d014 r4:c2695b00 [ 1946.617522] [] (ffs_data_closed [usb_f_fs • https://git.kernel.org/stable/c/5e33f6fdf735cda1d4580fe6f1878da05718fe73 https://git.kernel.org/stable/c/f976dd7011150244a7ba820f2c331e9fb253befa https://git.kernel.org/stable/c/cc8c8028c21b2a3842a1e98e99e55028df275919 https://git.kernel.org/stable/c/52500239e3f2d6fc77b6f58632a9fb98fe74ac09 https://git.kernel.org/stable/c/33f6a0cbb7772146e1c11f38028fffbfed14728b https://git.kernel.org/stable/c/240fc586e83d645912accce081a48aa63a45f6ee https://git.kernel.org/stable/c/1c4ace3e6b8575745c50dca9e76e0021e697d645 https://git.kernel.org/stable/c/ebef2aa29f370b5096c16020c104e3931 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-46932 – Input: appletouch - initialize work before device registration
https://notcve.org/view.php?id=CVE-2021-46932
In the Linux kernel, the following vulnerability has been resolved: Input: appletouch - initialize work before device registration Syzbot has reported warning in __flush_work(). This warning is caused by work->func == NULL, which means missing work initialization. This may happen, since input_dev->close() calls cancel_work_sync(&dev->work), but dev->work initalization happens _after_ input_register_device() call. So this patch moves dev->work initialization before registering input device En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Entrada: appletouch: inicializa el trabajo antes del registro del dispositivo Syzbot ha informado una advertencia en __flush_work(). Esta advertencia es causada por work->func == NULL, lo que significa que falta la inicialización del trabajo. Esto puede suceder, ya que input_dev->close() llama a cancel_work_sync(&dev->work), pero la inicialización dev->work ocurre _después_ de la llamada input_register_device(). Entonces este parche mueve la inicialización dev->work antes de registrar el dispositivo de entrada • https://git.kernel.org/stable/c/5a6eb676d3bc4d7a6feab200a92437b62ad298da https://git.kernel.org/stable/c/d2cb2bf39a6d17ef4bdc0e59c1a35cf5751ad8f4 https://git.kernel.org/stable/c/d1962f263a176f493400b8f91bfbf2bfedce951e https://git.kernel.org/stable/c/292d2ac61fb0d9276a0f7b7ce4f50426f2a1c99f https://git.kernel.org/stable/c/a02e1404e27855089d2b0a0acc4652c2ce65fe46 https://git.kernel.org/stable/c/975774ea7528b489930b76a77ffc4d5379b95ff2 https://git.kernel.org/stable/c/9f329d0d6c91142cf0ad08d23c72dd195db2633c https://git.kernel.org/stable/c/e79ff8c68acb1eddf709d3ac84716868f • CWE-665: Improper Initialization •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-46928 – parisc: Clear stale IIR value on instruction access rights trap
https://notcve.org/view.php?id=CVE-2021-46928
In the Linux kernel, the following vulnerability has been resolved: parisc: Clear stale IIR value on instruction access rights trap When a trap 7 (Instruction access rights) occurs, this means the CPU couldn't execute an instruction due to missing execute permissions on the memory region. In this case it seems the CPU didn't even fetched the instruction from memory and thus did not store it in the cr19 (IIR) register before calling the trap handler. So, the trap handler will find some random old stale value in cr19. This patch simply overwrites the stale IIR value with a constant magic "bad food" value (0xbaadf00d), in the hope people don't start to try to understand the various random IIR values in trap 7 dumps. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: parisc: borra el valor IIR obsoleto en la trampa de derechos de acceso a instrucciones Cuando ocurre una trampa 7 (derechos de acceso a instrucciones), esto significa que la CPU no pudo ejecutar una instrucción debido a que faltan permisos de ejecución en la región de la memoria. En este caso, parece que la CPU ni siquiera obtuvo la instrucción de la memoria y, por lo tanto, no la almacenó en el registro cr19 (IIR) antes de llamar al controlador de trampas. • https://git.kernel.org/stable/c/d01e9ce1af6116f812491d3d3873d204f10ae0b8 https://git.kernel.org/stable/c/e96373f0a5f484bc1e193f9951dcb3adf24bf3f7 https://git.kernel.org/stable/c/484730e5862f6b872dca13840bed40fd7c60fa26 • CWE-755: Improper Handling of Exceptional Conditions •