Page 410 of 3239 results (0.015 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in lpi2c_imx_master_enable. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: imx-lpi2c: corrige la fuga de referencia cuando falla pm_runtime_get_sync No se espera que el recuento de referencias de PM aumente al regresar en lpi2c_imx_master_enable. Sin embargo, pm_runtime_get_sync incrementará el recuento de referencias de PM incluso si falla. Olvidarse de poner en funcionamiento resultará en una fuga de referencia aquí. • https://git.kernel.org/stable/c/13d6eb20fc79a1e606307256dad4098375539a09 https://git.kernel.org/stable/c/815859cb1d2302e74f11bf6894bceace9ca9eb4a https://git.kernel.org/stable/c/cc49d206414240483bb93ffa3d80243e6a776916 https://git.kernel.org/stable/c/bb300acc867e937edc2a6898e92b21f88e4e4e66 https://git.kernel.org/stable/c/b100650d80cd2292f6c152f5f2943b5944b3e8ce https://git.kernel.org/stable/c/278e5bbdb9a94fa063c0f9bcde2479d0b8042462 •

CVSS: 4.7EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: i2c: sprd: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in sprd_i2c_master_xfer() and sprd_i2c_remove(). However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: sprd: corrige la fuga de referencia cuando falla pm_runtime_get_sync No se espera que el recuento de referencias de PM aumente al regresar en sprd_i2c_master_xfer() y sprd_i2c_remove(). Sin embargo, pm_runtime_get_sync incrementará el recuento de referencias de PM incluso si falla. Olvidarse de poner en funcionamiento resultará en una fuga de referencia aquí. • https://git.kernel.org/stable/c/8b9ec0719834fe66146d138d62ed66cef025c864 https://git.kernel.org/stable/c/7e1764312440c5df9dfe6b436035a03673b0c1b9 https://git.kernel.org/stable/c/e547640cee7981fd751d2c9cde3a61bdb678b755 https://git.kernel.org/stable/c/9223505e938ba3db5907e058f4209770cff2f2a7 https://git.kernel.org/stable/c/d3406ab52097328a3bc4cbe124bfd8f6d51fb86f https://git.kernel.org/stable/c/3a4f326463117cee3adcb72999ca34a9aaafda93 •

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

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix masking negation logic upon negative dst register The negation logic for the case where the off_reg is sitting in the dst register is not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and finally use AX as the source for the original pointer arithmetic operation such that the inversion yields a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as it's not an immediate based operation. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige la lógica de negación de enmascaramiento en el registro dst negativo. La lógica de negación para el caso en el que off_reg se encuentra en el registro dst no es correcta, dado que entonces no podemos simplemente invertir la adición a un sub o viceversa. • https://git.kernel.org/stable/c/ae03b6b1c880a03d4771257336dc3bca156dd51b https://git.kernel.org/stable/c/f92a819b4cbef8c9527d9797110544b2055a4b96 https://git.kernel.org/stable/c/979d63d50c0c0f7bc537bf821e056cc9fe5abd38 https://git.kernel.org/stable/c/078da99d449f64ca04d459cdbdcce513b64173cd https://git.kernel.org/stable/c/4d542ddb88fb2f39bf7f14caa2902f3e8d06f6ba https://git.kernel.org/stable/c/0e2dfdc74a7f4036127356d42ea59388f153f42c https://git.kernel.org/stable/c/53e0db429b37a32b8fc706d0d90eb4583ad13848 https://git.kernel.org/stable/c/2cfa537674cd1051a3b8111536d77d055 •

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

In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown state is queried unconditionally, even though its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesn't matter in case of the Lockdown LSM, it causes trouble with the SELinux's lockdown hook implementation. SELinux implements the locked_down hook with a check whether the current task's type has the corresponding "lockdown" class permission ("integrity" or "confidentiality") allowed in the policy. This means that calling the hook when the access control decision would be ignored generates a bogus permission check and audit record. Fix this by checking sample_type first and only calling the hook when its result would be honored. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf/core: corrige la llamada incondicional a security_locked_down() Actualmente, el estado de bloqueo se consulta incondicionalmente, aunque su resultado se usa solo si el bit PERF_SAMPLE_REGS_INTR está establecido en attr.sample_type. Si bien eso no importa en el caso del Lockdown LSM, causa problemas con la implementación del gancho de bloqueo de SELinux. • https://git.kernel.org/stable/c/b0c8fdc7fdb77586c3d1937050925b960743306e https://git.kernel.org/stable/c/b246759284d6a2bc5b6f1009caeeb3abce2ec9ff https://git.kernel.org/stable/c/4348d3b5027bc3ff6336368b6c60605d4ef8e1ce https://git.kernel.org/stable/c/f5809ca4c311b71bfaba6d13f4e39eab0557895e https://git.kernel.org/stable/c/c7b0208ee370b89d20486fae71cd9abb759819c1 https://git.kernel.org/stable/c/08ef1af4de5fe7de9c6d69f1e22e51b66e385d9b •

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

In the Linux kernel, the following vulnerability has been resolved: ACPI: custom_method: fix potential use-after-free issue In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: custom_method: soluciona un posible problema de use-after-free En cm_write(), buf siempre se libera al llegar al final de la función. Si el recuento solicitado es menor que table.length, el búfer asignado se liberará, pero las llamadas posteriores a cm_write() seguirán intentando acceder a él. Elimine el kfree(buf) incondicional al final de la función y establezca el buf en NULL en la ruta de error -EINVAL para que coincida con el resto de la función. • https://git.kernel.org/stable/c/4bda2b79a9d04c8ba31681c66e95877dbb433416 https://git.kernel.org/stable/c/5c12dadcbef8cd55ef1f5dac799bfcbb7ea7db1d https://git.kernel.org/stable/c/35b88a10535edcf62d3e6b7893a8cd506ff98a24 https://git.kernel.org/stable/c/e4467fb6ef547aa352dc03397f9474ec84eced5b https://git.kernel.org/stable/c/03d1571d9513369c17e6848476763ebbd10ec2cb https://git.kernel.org/stable/c/70424999fbf1f160ade111cb9baab51776e0f9c2 https://git.kernel.org/stable/c/06cd4a06eb596a888239fb8ceb6ea15677cab396 https://git.kernel.org/stable/c/1d53ca5d131074c925ce38361fb0376d3 •