Page 155 of 2910 results (0.011 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: isofs: Fix out of bound access for corrupted isofs image When isofs image is suitably corrupted isofs_read_inode() can read data beyond the end of buffer. Sanity-check the directory entry length before using it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: isofs: corrige el acceso fuera de los límites para una imagen isofs corrupta. Cuando la imagen isofs está adecuadamente dañada, isofs_read_inode() puede leer datos más allá del final del búfer. Cordura: verifique la longitud de la entrada del directorio antes de usarla. • https://git.kernel.org/stable/c/156ce5bb6cc43a80a743810199defb1dc3f55b7f https://git.kernel.org/stable/c/9ec33a9b8790c212cc926a88c5e2105f97f3f57e https://git.kernel.org/stable/c/afbd40f425227e661d991757e11cc4db024e761f https://git.kernel.org/stable/c/b0ddff8d68f2e43857a84dce54c3deab181c8ae1 https://git.kernel.org/stable/c/6e80e9314f8bb52d9eabe1907698718ff01120f5 https://git.kernel.org/stable/c/86d4aedcbc69c0f84551fb70f953c24e396de2d7 https://git.kernel.org/stable/c/b2fa1f52d22c5455217b294629346ad23a744945 https://git.kernel.org/stable/c/e7fb722586a2936b37bdff096c095c30c • CWE-125: Out-of-bounds Read •

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

In the Linux kernel, the following vulnerability has been resolved: comedi: dt9812: fix DMA buffers on stack USB transfer buffers are typically mapped for DMA and must not be allocated on the stack or transfers will fail. Allocate proper transfer buffers in the various command helpers and return an error on short transfers instead of acting on random stack data. Note that this also fixes a stack info leak on systems where DMA is not used as 32 bytes are always sent to the device regardless of how short the command is. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: comedi: dt9812: corrige los búferes DMA en la pila Los búferes de transferencia USB generalmente están asignados para DMA y no deben asignarse en la pila o las transferencias fallarán. Asigne búferes de transferencia adecuados en los distintos asistentes de comando y devuelva un error en transferencias cortas en lugar de actuar sobre datos de pila aleatorios. Tenga en cuenta que esto también soluciona una fuga de información de la pila en sistemas donde no se usa DMA, ya que siempre se envían 32 bytes al dispositivo, independientemente de cuán corto sea el comando. • https://git.kernel.org/stable/c/63274cd7d38a3322d90b66a5bc976de1fb899051 https://git.kernel.org/stable/c/a6af69768d5cb4b2528946d53be5fa19ade37723 https://git.kernel.org/stable/c/365a346cda82f51d835c49136a00a9df8a78c7f2 https://git.kernel.org/stable/c/8a52bc480992c7c9da3ebfea456af731f50a4b97 https://git.kernel.org/stable/c/39ea61037ae78f14fa121228dd962ea3280eacf3 https://git.kernel.org/stable/c/3efb7af8ac437085b6c776e5b54830b149d86efe https://git.kernel.org/stable/c/786f5b03450454557ff858a8bead5d7c0cbf78d6 https://git.kernel.org/stable/c/3ac273d154d634e2034508a14db82a95d •

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

In the Linux kernel, the following vulnerability has been resolved: comedi: vmk80xx: fix transfer-buffer overflows The driver uses endpoint-sized USB transfer buffers but up until recently had no sanity checks on the sizes. Commit e1f13c879a7c ("staging: comedi: check validity of wMaxPacketSize of usb endpoints found") inadvertently fixed NULL-pointer dereferences when accessing the transfer buffers in case a malicious device has a zero wMaxPacketSize. Make sure to allocate buffers large enough to handle also the other accesses that are done without a size check (e.g. byte 18 in vmk80xx_cnt_insn_read() for the VMK8061_MODEL) to avoid writing beyond the buffers, for example, when doing descriptor fuzzing. The original driver was for a low-speed device with 8-byte buffers. Support was later added for a device that uses bulk transfers and is presumably a full-speed device with a maximum 64-byte wMaxPacketSize. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: comedi: vmk80xx: corrige desbordamientos del búfer de transferencia El controlador utiliza búferes de transferencia USB del tamaño de un terminal, pero hasta hace poco no tenía controles de cordura sobre los tamaños. el commit e1f13c879a7c ("staging: comedi: verificar la validez de wMaxPacketSize de los endpoints USB encontrados") corrigió inadvertidamente las desreferencias de puntero NULL al acceder a los buffers de transferencia en caso de que un dispositivo malicioso tenga un wMaxPacketSize cero. Asegúrese de asignar buffers lo suficientemente grandes para manejar también los otros accesos que se realizan sin una verificación de tamaño (por ejemplo, el byte 18 en vmk80xx_cnt_insn_read() para VMK8061_MODEL) para evitar escribir más allá de los buffers, por ejemplo, cuando se realiza una confusión de descriptores. El controlador original era para un dispositivo de baja velocidad con buffers de 8 bytes. Posteriormente se agregó soporte para un dispositivo que utiliza transferencias masivas y presumiblemente es un dispositivo de velocidad completa con un wMaxPacketSize máximo de 64 bytes. • https://git.kernel.org/stable/c/985cafccbf9b7f862aa1c5ee566801e18b5161fb https://git.kernel.org/stable/c/5229159f1d052821007aff1a1beb7873eacf1a9f https://git.kernel.org/stable/c/ec85bcff4ed09260243d8f39faba99e1041718ba https://git.kernel.org/stable/c/40d2a7e278e2e7c0a5fd7e997e7eb63945bf93f7 https://git.kernel.org/stable/c/7a2021b896de1ad559d33b5c5cdd20b982242088 https://git.kernel.org/stable/c/199acd8c110e3ae62833c24f632b0bb1c9f012a9 https://git.kernel.org/stable/c/33d7a470730dfe7c9bfc8da84575cf2cedd60d00 https://git.kernel.org/stable/c/278484ae93297b1bb1ce755f9d3b6d95a •

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

In the Linux kernel, the following vulnerability has been resolved: comedi: vmk80xx: fix bulk-buffer overflow The driver is using endpoint-sized buffers but must not assume that the tx and rx buffers are of equal size or a malicious device could overflow the slab-allocated receive buffer when doing bulk transfers. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: comedi: vmk80xx: corrige el desbordamiento masivo del búfer El controlador utiliza búferes del tamaño de un endpoint, pero no debe asumir que los búferes tx y rx son del mismo tamaño o un dispositivo malicioso podría desbordar el búfer de recepción asignado por losa al realizar transferencias masivas. • https://git.kernel.org/stable/c/985cafccbf9b7f862aa1c5ee566801e18b5161fb https://git.kernel.org/stable/c/e0e6a63fd97ad95fe05dfd77268a1952551e11a7 https://git.kernel.org/stable/c/7cfb35db607760698d299fd1cf7402dfa8f09973 https://git.kernel.org/stable/c/0866dcaa828c21bc2f94dac00e086078f11b5772 https://git.kernel.org/stable/c/063f576c43d589a4c153554b681d32b3f8317c7b https://git.kernel.org/stable/c/1ae4715121a57bc6fa29fd992127b01907f2f993 https://git.kernel.org/stable/c/b7fd7f3387f070215e6be341e68eb5c087eeecc0 https://git.kernel.org/stable/c/7b0e356189327287d0eb98ec081bd6dd9 •

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

In the Linux kernel, the following vulnerability has been resolved: spi: Fix deadlock when adding SPI controllers on SPI buses Currently we have a global spi_add_lock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of doing so for the parent controller and hence already holding the global spi_add_lock. Since we only care about concurrency within a single SPI bus move the lock to be per controller, avoiding the deadlock. This can be easily triggered in the case of spi-mux. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: soluciona el punto muerto al agregar controladores SPI en buses SPI. Actualmente tenemos un spi_add_lock global que utilizamos cuando agregamos nuevos dispositivos para que podamos verificar que no estamos intentando reutilizar un selección de chip que ya está controlado. • https://git.kernel.org/stable/c/aa3f3d7bef59583f2d3234173105a27ff61ef8fe https://git.kernel.org/stable/c/c8dce228db6f81dbc897a018dfc5c418e917cf64 https://git.kernel.org/stable/c/722ef19a161ce3fffb3d1b01ce2301c306639bdd https://git.kernel.org/stable/c/6098475d4cb48d821bdf453c61118c56e26294f0 •