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: 6EXPL: 0CVE-2021-46935 – binder: fix async_free_space accounting for empty parcels
https://notcve.org/view.php?id=CVE-2021-46935
In the Linux kernel, the following vulnerability has been resolved: binder: fix async_free_space accounting for empty parcels In 4.13, commit 74310e06be4d ("android: binder: Move buffer out of area shared with user space") fixed a kernel structure visibility issue. As part of that patch, sizeof(void *) was used as the buffer size for 0-length data payloads so the driver could detect abusive clients sending 0-length asynchronous transactions to a server by enforcing limits on async_free_size. Unfortunately, on the "free" side, the accounting of async_free_space did not add the sizeof(void *) back. The result was that up to 8-bytes of async_free_space were leaked on every async transaction of 8-bytes or less. These small transactions are uncommon, so this accounting issue has gone undetected for several years. The fix is to use "buffer_size" (the allocated buffer size) instead of "size" (the logical buffer size) when updating the async_free_space during the free operation. These are the same except for this corner case of asynchronous transactions with payloads < 8 bytes. • https://git.kernel.org/stable/c/74310e06be4d74dcf67cd108366710dee5c576d5 https://git.kernel.org/stable/c/2d2df539d05205fd83c404d5f2dff48d36f9b495 https://git.kernel.org/stable/c/7c7064402609aeb6fb11be1b4ec10673ff17b593 https://git.kernel.org/stable/c/103b16a8c51f96d5fe063022869ea906c256e5da https://git.kernel.org/stable/c/1cb8444f3114f0bb2f6e3bcadcf09aa4a28425d4 https://git.kernel.org/stable/c/17691bada6b2f1d5f1c0f6d28cd9d0727023b0ff https://git.kernel.org/stable/c/cfd0d84ba28c18b531648c9d4a35ecca89ad9901 • CWE-668: Exposure of Resource to Wrong Sphere •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46934 – i2c: validate user data in compat ioctl
https://notcve.org/view.php?id=CVE-2021-46934
In the Linux kernel, the following vulnerability has been resolved: i2c: validate user data in compat ioctl Wrong user data may cause warning in i2c_transfer(), ex: zero msgs. Userspace should not be able to trigger warnings, so this patch adds validation checks for user data in compact ioctl to prevent reported warnings En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: validar datos de usuario en compat ioctl Los datos de usuario incorrectos pueden causar advertencia en i2c_transfer(), ej: cero mensajes. El espacio de usuario no debería poder activar advertencias, por lo que este parche agrega comprobaciones de validación para los datos del usuario en ioctl compacto para evitar advertencias reportadas. • https://git.kernel.org/stable/c/7d5cb45655f2e9e37ef75d18f50c0072ef14a38b https://git.kernel.org/stable/c/407c8708fb1bf2d4afc5337ef50635cf540c364b https://git.kernel.org/stable/c/9e4a3f47eff476097e0c7faac04d1831fc70237d https://git.kernel.org/stable/c/8d31cbab4c295d7010ebb729e9d02d0e9cece18f https://git.kernel.org/stable/c/f68599581067e8a5a8901ba9eb270b4519690e26 https://git.kernel.org/stable/c/bb436283e25aaf1533ce061605d23a9564447bdf https://access.redhat.com/security/cve/CVE-2021-46934 https://bugzilla.redhat.com/show_bug.cgi?id=2266446 • CWE-703: Improper Check or Handling of Exceptional Conditions CWE-754: Improper Check for Unusual or Exceptional Conditions •
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 •