Page 147 of 2884 results (0.006 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix negative period/buffer sizes The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t. Due to that, a too big value may be passed to the lower layers. This patch changes the code to handle with ssize_t and adds the proper error checks appropriately. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: oss: corrige tamaños de período/búfer negativos El cálculo del tamaño del período en la capa OSS puede recibir un valor negativo como error, pero el código allí asume solo los valores positivos y manejarlos con size_t. Debido a esto, es posible que se pase un valor demasiado grande a las capas inferiores. Este parche cambia el código para manejar con ssize_t y agrega las comprobaciones de errores adecuadas. • https://git.kernel.org/stable/c/be8869d388593e57223ad39297c8e54be632f2f2 https://git.kernel.org/stable/c/502e1146873d870f87da3b8f93d6bf2de5f38d0c https://git.kernel.org/stable/c/8af815ab052eaf74addbbfb556d63ce2137c0e1b https://git.kernel.org/stable/c/f96c0959c1ee92adc911c10d6ec209af50105049 https://git.kernel.org/stable/c/f12c8a7515f641885677960af450082569a87243 https://git.kernel.org/stable/c/02b2b691b77cd7b951fa7b6c9d44d4e472cdc823 https://git.kernel.org/stable/c/00a860678098fcd9fa8db2b5fb9d2ddf4776d4cc https://git.kernel.org/stable/c/9d2479c960875ca1239bcb899f386970c •

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

In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Limit the period size to 16MB Set the practical limit to the period size (the fragment shift in OSS) instead of a full 31bit; a too large value could lead to the exhaust of memory as we allocate temporary buffers of the period size, too. As of this patch, we set to 16MB limit, which should cover all use cases. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: oss: Limitar el tamaño del período a 16 MB Establezca el límite práctico para el tamaño del período (el desplazamiento de fragmentos en OSS) en lugar de 31 bits completos; un valor demasiado grande podría provocar el agotamiento de la memoria, ya que también asignamos búferes temporales del tamaño del período. A partir de este parche, establecimos un límite de 16 MB, que debería cubrir todos los casos de uso. • https://git.kernel.org/stable/c/d1bb703ad050de9095f10b2d3416c32921ac6bcc https://git.kernel.org/stable/c/b02a41eebcc36d4f07196780f2e165ca2c499257 https://git.kernel.org/stable/c/be55f306396cd62c6889286a7194fd8b53363aeb https://git.kernel.org/stable/c/2e54cf6794bf82a54aaefc78da13819aea9cd28a https://git.kernel.org/stable/c/76f19e4cbb548e28547f8c328aa0bfb3a10222d3 https://git.kernel.org/stable/c/ad45babf7886e7a212ee1d5eda9ef49f696db43c https://git.kernel.org/stable/c/35a3e511032146941085f87dd9fb5b82ea5c00a2 https://git.kernel.org/stable/c/8839c8c0f77ab8fc0463f4ab8b37fca3f •

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: free exchange changeset on failures Fstests runs on my VMs have show several kmemleak reports like the following. unreferenced object 0xffff88811ae59080 (size 64): comm "xfs_io", pid 12124, jiffies 4294987392 (age 6.368s) hex dump (first 32 bytes): 00 c0 1c 00 00 00 00 00 ff cf 1c 00 00 00 00 00 ................ 90 97 e5 1a 81 88 ff ff 90 97 e5 1a 81 88 ff ff ................ backtrace: [<00000000ac0176d2>] ulist_add_merge+0x60/0x150 [btrfs] [<0000000076e9f312>] set_state_bits+0x86/0xc0 [btrfs] [<0000000014fe73d6>] set_extent_bit+0x270/0x690 [btrfs] [<000000004f675208>] set_record_extent_bits+0x19/0x20 [btrfs] [<00000000b96137b1>] qgroup_reserve_data+0x274/0x310 [btrfs] [<0000000057e9dcbb>] btrfs_check_data_free_space+0x5c/0xa0 [btrfs] [<0000000019c4511d>] btrfs_delalloc_reserve_space+0x1b/0xa0 [btrfs] [<000000006d37e007>] btrfs_dio_iomap_begin+0x415/0x970 [btrfs] [<00000000fb8a74b8>] iomap_iter+0x161/0x1e0 [<0000000071dff6ff>] __iomap_dio_rw+0x1df/0x700 [<000000002567ba53>] iomap_dio_rw+0x5/0x20 [<0000000072e555f8>] btrfs_file_write_iter+0x290/0x530 [btrfs] [<000000005eb3d845>] new_sync_write+0x106/0x180 [<000000003fb505bf>] vfs_write+0x24d/0x2f0 [<000000009bb57d37>] __x64_sys_pwrite64+0x69/0xa0 [<000000003eba3fdf>] do_syscall_64+0x43/0x90 In case brtfs_qgroup_reserve_data() or btrfs_delalloc_reserve_metadata() fail the allocated extent_changeset will not be freed. So in btrfs_check_data_free_space() and btrfs_delalloc_reserve_space() free the allocated extent_changeset to get rid of the allocated memory. The issue currently only happens in the direct IO write path, but only after 65b3c08606e5 ("btrfs: fix ENOSPC failure when attempting direct IO write into NOCOW range"), and also at defrag_one_locked_target(). Every other place is always calling extent_changeset_free() even if its call to btrfs_delalloc_reserve_space() or btrfs_check_data_free_space() has failed. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: conjunto de cambios de intercambio gratuito en caso de fallas. Las ejecuciones de Fstests en mis VM han mostrado varios informes de kmemleak como el siguiente. objeto sin referencia 0xffff88811ae59080 (tamaño 64): comm "xfs_io", pid 12124, jiffies 4294987392 (edad 6,368 s) volcado hexadecimal (primeros 32 bytes): 00 c0 1c 00 00 00 00 00 ff cf 1c 00 00 00 00... ............. 90 97 e5 1a 81 88 ff ff 90 97 e5 1a 81 88 ff ff ................ retroceso: [&lt;00000000ac0176d2 &gt;] ulist_add_merge+0x60/0x150 [btrfs] [&lt;0000000076e9f312&gt;] set_state_bits+0x86/0xc0 [btrfs] [&lt;0000000014fe73d6&gt;] set_extent_bit+0x270/0x690 [btrfs] [&lt;000000004f 675208&gt;] set_record_extent_bits+0x19/0x20 [btrfs] [ &lt;00000000b96137b1&gt;] qgroup_reserve_data+0x274/0x310 [btrfs] [&lt;0000000057e9dcbb&gt;] btrfs_check_data_free_space+0x5c/0xa0 [btrfs] [&lt;0000000019c4511d&gt;] +0x1b/0xa0 [btrfs] [&lt;000000006d37e007&gt;] btrfs_dio_iomap_begin+0x415/0x970 [btrfs ] [&lt;00000000fb8a74b8&gt;] iomap_iter+0x161/0x1e0 [&lt;0000000071dff6ff&gt;] __iomap_dio_rw+0x1df/0x700 [&lt;000000002567ba53&gt;] iomap_dio_rw+0x5/0x20 [&lt;000000 0072e555f8&gt;] btrfs_file_write_iter+0x290/0x530 [btrfs] [&lt;000000005eb3d845&gt;] new_sync_write +0x106/0x180 [&lt;000000003fb505bf&gt;] vfs_write+0x24d/0x2f0 [&lt;000000009bb57d37&gt;] __x64_sys_pwrite64+0x69/0xa0 [&lt;000000003eba3fdf&gt;] 3/0x90 En caso de que brtfs_qgroup_reserve_data() o btrfs_delalloc_reserve_metadata() fallen, el conjunto de cambios asignado no será liberado. Entonces, en btrfs_check_data_free_space() y btrfs_delalloc_reserve_space() libera el extend_changeset asignado para deshacerte de la memoria asignada. • https://git.kernel.org/stable/c/ca06c5cb1b6dbfe67655b33c02fc394d65824519 https://git.kernel.org/stable/c/da5e817d9d75422eaaa05490d0b9a5e328fc1a51 •

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

In the Linux kernel, the following vulnerability has been resolved: nfsd: fix use-after-free due to delegation race A delegation break could arrive as soon as we've called vfs_setlease. A delegation break runs a callback which immediately (in nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru. If we then exit nfs4_set_delegation without hashing the delegation, it will be freed as soon as the callback is done with it, without ever being removed from del_recall_lru. Symptoms show up later as use-after-free or list corruption warnings, usually in the laundromat thread. I suspect aba2072f4523 "nfsd: grant read delegations to clients holding writes" made this bug easier to hit, but I looked as far back as v3.0 and it looks to me it already had the same problem. So I'm not sure where the bug was introduced; it may have been there from the beginning. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrige el use-after-free debido a la ejecución de delegación. • https://git.kernel.org/stable/c/04a8d07f3d58308b92630045560799a3faa3ebce https://git.kernel.org/stable/c/348714018139c39533c55661a0c7c990671396b4 https://git.kernel.org/stable/c/33645d3e22720cac1e4548f8fef57bf0649536ee https://git.kernel.org/stable/c/2becaa990b93cbd2928292c0b669d3abb6cf06d4 https://git.kernel.org/stable/c/e0759696de6851d7536efddfdd2dfed4c4df1f09 https://git.kernel.org/stable/c/eeb0711801f5e19ef654371b627682aed3b11373 https://git.kernel.org/stable/c/148c816f10fd11df27ca6a9b3238cdd42fa72cd3 https://git.kernel.org/stable/c/548ec0805c399c65ed66c6641be467f71 •

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

In the Linux kernel, the following vulnerability has been resolved: io_uring: ensure task_work gets run as part of cancelations If we successfully cancel a work item but that work item needs to be processed through task_work, then we can be sleeping uninterruptibly in io_uring_cancel_generic() and never process it. Hence we don't make forward progress and we end up with an uninterruptible sleep warning. While in there, correct a comment that should be IFF, not IIF. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: garantiza que task_work se ejecute como parte de las cancelaciones. Si cancelamos con éxito un elemento de trabajo pero ese elemento de trabajo debe procesarse a través de task_work, entonces podemos estar durmiendo ininterrumpidamente en io_uring_cancel_generic() y nunca procesarlo. Por lo tanto, no avanzamos y terminamos con un aviso de sueño ininterrumpido. • https://git.kernel.org/stable/c/8e12976c0c19ebc14b60046b1348c516a74c25a2 https://git.kernel.org/stable/c/78a780602075d8b00c98070fa26e389b3b3efa72 •