Page 108 of 2608 results (0.012 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fec: elimine .ndo_poll_controller para evitar interbloqueos. • https://git.kernel.org/stable/c/7f5c6addcdc039c1a7c435857e6284ecac5d97c8 https://git.kernel.org/stable/c/d38625f71950e79e254515c5fc585552dad4b33e https://git.kernel.org/stable/c/accdd6b912c4219b8e056d1f1ad2e85bc66ee243 https://git.kernel.org/stable/c/87bcbc9b7e0b43a69d44efa5f32f11e32d08fa6f https://git.kernel.org/stable/c/c2e0c58b25a0a0c37ec643255558c5af4450c9f5 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Add 0 size check to mtk_drm_gem_obj Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/mediatek: Agregar verificación de tamaño 0 a mtk_drm_gem_obj Agregar una verificación a mtk_drm_gem_init si intentamos asignar un objeto GEM de 0 bytes. Actualmente, no existe tal verificación y el kernel entrará en pánico si una aplicación de espacio de usuario intenta asignar un búfer GBM 0x0. Probado intentando asignar un búfer GBM 0x0 en un MT8188 y verificando que ahora devolvemos EINVAL. • https://git.kernel.org/stable/c/119f5173628aa7a0c3cf9db83460d40709e8241d https://git.kernel.org/stable/c/79078880795478d551a05acc41f957700030d364 https://git.kernel.org/stable/c/be34a1b351ea7faeb15dde8c44fe89de3980ae67 https://git.kernel.org/stable/c/d17b75ee9c2e44d3a3682c4ea5ab713ea6073350 https://git.kernel.org/stable/c/0e3b6f9123726858cac299e1654e3d20424cabe4 https://git.kernel.org/stable/c/13562c2d48c9ee330de1077d00146742be368f05 https://git.kernel.org/stable/c/af26ea99019caee1500bf7e60c861136c0bf8594 https://git.kernel.org/stable/c/9489951e3ae505534c4013db4e76b1b5a •

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

In the Linux kernel, the following vulnerability has been resolved: media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: atomisp: ssh_css: corrige una desreferencia de puntero nulo en load_video_binaries La falla de asignación de mycs->yuv_scaler_binary en load_video_binaries() va seguida de una desreferencia de mycs->yuv_scaler_binary después de siguiente cadena de llamadas: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() En unload_video_binaries(), llama a ia_css_binary_unload con el argumento &pipe->pipe_settings.video.yuv_scaler_binary[i], que se refiere a la misma ranura de memoria que mycs->yuv_scaler_binary. Por lo tanto, se activa una desreferencia de puntero nulo. • https://git.kernel.org/stable/c/a49d25364dfb9f8a64037488a39ab1f56c5fa419 https://git.kernel.org/stable/c/4b68b861b514a5c09220d622ac3784c0ebac6c80 https://git.kernel.org/stable/c/82c2c85aead3ea3cbceef4be077cf459c5df2272 https://git.kernel.org/stable/c/a1ab99dcc8604afe7e3bccb01b10da03bdd7ea35 https://git.kernel.org/stable/c/cc20c87b04db86c8e3e810bcdca686b406206069 https://git.kernel.org/stable/c/69b27ff82f87379afeaaea4b2f339032fdd8486e https://git.kernel.org/stable/c/6482c433863b257b0b9b687c28ce80b89d5f89f0 https://git.kernel.org/stable/c/3b621e9e9e148c0928ab109ac3d4b8148 •

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

In the Linux kernel, the following vulnerability has been resolved: drm: vc4: Fix possible null pointer dereference In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: vc4: corrige posible desreferencia del puntero nulo En vc4_hdmi_audio_init() of_get_address() puede devolver NULL, que luego se desreferencia. Corrija este error agregando una verificación NULL. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/bb7d78568814a31a11fa14f1479a9fe51f1582ad https://git.kernel.org/stable/c/2d9adecc88ab678785b581ab021f039372c324cb https://git.kernel.org/stable/c/6cf1874aec42058a5ad621a23b5b2f248def0e96 https://git.kernel.org/stable/c/80431ea3634efb47a3004305d76486db9dd8ed49 https://git.kernel.org/stable/c/42c22b63056cea259d5313bf138a834840af85a5 https://git.kernel.org/stable/c/2a345fe928c21de6f3c3c7230ff509d715153a31 https://git.kernel.org/stable/c/bd7827d46d403f8cdb43d16744cb1114e4726b21 https://git.kernel.org/stable/c/c534b63bede6cb987c2946ed4d0b0013a •

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

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix UAF for cq async event The refcount of CQ is not protected by locks. When CQ asynchronous events and CQ destruction are concurrent, CQ may have been released, which will cause UAF. Use the xa_lock() to protect the CQ refcount. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/hns: corrige UAF para el evento cq async El recuento de CQ no está protegido por bloqueos. Cuando los eventos asincrónicos de CQ y la destrucción de CQ son simultáneos, es posible que se haya liberado CQ, lo que provocará UAF. Utilice xa_lock() para proteger el recuento de CQ. • https://git.kernel.org/stable/c/9a4435375cd151e07c0c38fa601b00115986091b https://git.kernel.org/stable/c/763780ef0336a973e933e40e919339381732dcaf https://git.kernel.org/stable/c/63da190eeb5c9d849b71f457b15b308c94cbaf08 https://git.kernel.org/stable/c/39d26cf46306bdc7ae809ecfdbfeff5aa1098911 https://git.kernel.org/stable/c/37a7559dc1358a8d300437e99ed8ecdab0671507 https://git.kernel.org/stable/c/a942ec2745ca864cd8512142100e4027dc306a42 •