Page 710 of 4743 results (0.012 seconds)

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

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: 5.5EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/cpufreq_cooling: Fix slab OOB issue Slab OOB issue is scanned by KASAN in cpu_power_to_freq(). If power is limited below the power of OPP0 in EM table, it will cause slab out-of-bound issue with negative array index. Return the lowest frequency if limited power cannot found a suitable OPP in EM table to fix this issue. Backtrace: [<ffffffd02d2a37f0>] die+0x104/0x5ac [<ffffffd02d2a5630>] bug_handler+0x64/0xd0 [<ffffffd02d288ce4>] brk_handler+0x160/0x258 [<ffffffd02d281e5c>] do_debug_exception+0x248/0x3f0 [<ffffffd02d284488>] el1_dbg+0x14/0xbc [<ffffffd02d75d1d4>] __kasan_report+0x1dc/0x1e0 [<ffffffd02d75c2e0>] kasan_report+0x10/0x20 [<ffffffd02d75def8>] __asan_report_load8_noabort+0x18/0x28 [<ffffffd02e6fce5c>] cpufreq_power2state+0x180/0x43c [<ffffffd02e6ead80>] power_actor_set_power+0x114/0x1d4 [<ffffffd02e6fac24>] allocate_power+0xaec/0xde0 [<ffffffd02e6f9f80>] power_allocator_throttle+0x3ec/0x5a4 [<ffffffd02e6ea888>] handle_thermal_trip+0x160/0x294 [<ffffffd02e6edd08>] thermal_zone_device_check+0xe4/0x154 [<ffffffd02d351cb4>] process_one_work+0x5e4/0xe28 [<ffffffd02d352f44>] worker_thread+0xa4c/0xfac [<ffffffd02d360124>] kthread+0x33c/0x358 [<ffffffd02d289940>] ret_from_fork+0xc/0x18 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Thermal/drivers/cpufreq_cooling: solucionar el problema de Slab OOB El problema de Slab OOB es escaneado por KASAN en cpu_power_to_freq(). Si la potencia se limita por debajo de la potencia de OPP0 en la tabla EM, provocará un problema de losa fuera de los límites con un índice de matriz negativo. Devuelve la frecuencia más baja si la potencia limitada no puede encontrar un OPP adecuado en la tabla EM para solucionar este problema. Seguimiento inverso: [] die+0x104/0x5ac [] bug_handler+0x64/0xd0 [] brk_handler+0x160/0x258 [] do_debug_exception+0x 248/0x3f0 [] el1_dbg+0x14 /0xbc [] __kasan_report+0x1dc/0x1e0 [] kasan_report+0x10/0x20 [] __asan_report_load8_noabort+0x18/0x28 [] cpufreq_power2state+0x180/0x43c [] power_actor_set_power+0x114 /0x1d4 [] allocate_power+0xaec/0xde0 [] power_allocator_throttle+0x3ec/0x5a4 [] handle_thermal_trip+0x160/0x294 [] térmico _zone_device_check+0xe4/0x154 [] proceso_one_work+0x5e4 /0xe28 [] work_thread+0xa4c/0xfac [] kthread+0x33c/0x358 [] ret_from_fork+0xc/0x18 • https://git.kernel.org/stable/c/371a3bc79c11b707d7a1b7a2c938dc3cc042fffb https://git.kernel.org/stable/c/39e0651cac9c80865b2838f297f95ffc0f34a1d8 https://git.kernel.org/stable/c/febe56f21371ba1e51e8586c3ddf8f54fc62fe61 https://git.kernel.org/stable/c/d3b7bacd1115400b94482dfc7efffc175c29b831 https://git.kernel.org/stable/c/9006b543384ab10902819364c1205f11a1458571 https://git.kernel.org/stable/c/c24a20912eef00587416628149c438e885eb1304 https://git.kernel.org/stable/c/876a5f33e5d961d879c5436987c09b3d9ef70379 https://git.kernel.org/stable/c/6bf443acf6ca4f666d0e4225614ba9993 • CWE-129: Improper Validation of Array Index •

CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: mm/damon/dbgfs: fix 'struct pid' leaks in 'dbgfs_target_ids_write()' DAMON debugfs interface increases the reference counts of 'struct pid's for targets from the 'target_ids' file write callback ('dbgfs_target_ids_write()'), but decreases the counts only in DAMON monitoring termination callback ('dbgfs_before_terminate()'). Therefore, when 'target_ids' file is repeatedly written without DAMON monitoring start/termination, the reference count is not decreased and therefore memory for the 'struct pid' cannot be freed. This commit fixes this issue by decreasing the reference counts when 'target_ids' is written. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/dbgfs: corrige las fugas de 'struct pid' en 'dbgfs_target_ids_write()' La interfaz DAMON debugfs aumenta los recuentos de referencias de 'struct pid' para los objetivos de la escritura del archivo 'target_ids' devolución de llamada ('dbgfs_target_ids_write()'), pero disminuye los recuentos solo en la devolución de llamada de terminación de monitoreo de DAMON ('dbgfs_before_terminate()'). Por lo tanto, cuando el archivo 'target_ids' se escribe repetidamente sin que DAMON supervise el inicio/terminación, el recuento de referencias no disminuye y, por lo tanto, no se puede liberar memoria para 'struct pid'. Este commit soluciona este problema al disminuir el recuento de referencias cuando se escribe 'target_ids'. • https://git.kernel.org/stable/c/4bc05954d0076655cfaf6f0135585bdc20cd6b11 https://git.kernel.org/stable/c/ffe4a1ba1a82c416a6b3a09d46594f6a885ae141 https://git.kernel.org/stable/c/ebb3f994dd92f8fb4d70c7541091216c1e10cb71 • CWE-668: Exposure of Resource to Wrong Sphere •

CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0

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: 0

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 •