Page 376 of 2372 results (0.014 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix OOB in nilfs_set_de_type The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t mode = inode->i_mode; de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob } However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige OOB en nilfs_set_de_type El tamaño de la matriz nilfs_type_by_mode en el archivo fs/nilfs2/dir.c se define como "S_IFMT >> S_SHIFT", pero la función nilfs_set_de_type() , que utiliza esta matriz, especifica el índice a leer de la matriz de la misma manera que "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t modo = inodo->i_mode; de->tipo_archivo = nilfs_type_by_mode[(modo & S_IFMT)>>S_SHIFT]; // oob } Sin embargo, cuando el índice se determina de esta manera, se produce un error fuera de los límites (OOB) al hacer referencia a un índice que es 1 mayor que el tamaño de la matriz cuando la condición "modo & S_IFMT == S_IFMT" es satisfecho. Por lo tanto, se debe aplicar un parche para cambiar el tamaño de la matriz nilfs_type_by_mode para evitar errores OOB. • https://git.kernel.org/stable/c/2ba466d74ed74f073257f86e61519cb8f8f46184 https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243 https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8 https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1 https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0 https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611 https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9 https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f •

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

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in smb2_allocate_rsp_buf(). This patch allocate response buffer after decrypting transform request. smb3_decrypt_req() will validate transform request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige slab-out-of-bounds en smb2_allocate_rsp_buf Si ->ProtocolId es SMB2_TRANSFORM_PROTO_NUM, se podría omitir la validación del tamaño de la solicitud smb2. Si el tamaño de la solicitud es menor que sizeof (struct smb2_query_info_req), la lectura de losa fuera de los límites puede ocurrir en smb2_allocate_rsp_buf(). Este parche asigna un búfer de respuesta después de descifrar la solicitud de transformación. smb3_decrypt_req() validará el tamaño de la solicitud de transformación y evitará la losa fuera de los límites en smb2_allocate_rsp_buf(). • https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325 https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248 https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1 https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085 https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20 •

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

In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate request buffer size in smb2_allocate_rsp_buf() The response buffer should be allocated in smb2_allocate_rsp_buf before validating request. But the fields in payload as well as smb2 header is used in smb2_allocate_rsp_buf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: validar el tamaño del búfer de solicitud en smb2_allocate_rsp_buf() El búfer de respuesta debe asignarse en smb2_allocate_rsp_buf antes de validar la solicitud. Pero los campos en el payload y el encabezado smb2 se usan en smb2_allocate_rsp_buf(). • https://git.kernel.org/stable/c/8f3d0bf1d0c62b539d54c5b9108a845cff619b99 https://git.kernel.org/stable/c/21ff9d7d223c5c19cb4334009e4c0c83a2f4d674 https://git.kernel.org/stable/c/5c20b242d4fed73a93591e48bfd9772e2322fb11 https://git.kernel.org/stable/c/2c27a64a2bc47d9bfc7c3cf8be14be53b1ee7cb6 https://git.kernel.org/stable/c/17cf0c2794bdb6f39671265aa18aea5c22ee8c4a •

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

In the Linux kernel, the following vulnerability has been resolved: serial: max310x: fix NULL pointer dereference in I2C instantiation When trying to instantiate a max14830 device from userspace: echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device we get the following error: Unable to handle kernel NULL pointer dereference at virtual address... ... Call trace: max310x_i2c_probe+0x48/0x170 [max310x] i2c_device_probe+0x150/0x2a0 ... Add check for validity of devtype to prevent the error, and abort probe with a meaningful error message. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: serial: max310x: corrige la desreferencia del puntero NULL en la creación de instancias I2C Al intentar crear una instancia de un dispositivo max14830 desde el espacio de usuario: echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/ new_device obtenemos el siguiente error: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual... ... Rastreo de llamadas: max310x_i2c_probe+0x48/0x170 [max310x] i2c_device_probe+0x150/0x2a0... Agregar verificación de validez del tipo de desarrollo para evitar el error y cancelar la sonda con un mensaje de error significativo. • https://git.kernel.org/stable/c/f5c252aaa1be5d38604e58e9bd335065f767d0d8 https://git.kernel.org/stable/c/85d79478710ad2cbf11857aec107084a7104943e https://git.kernel.org/stable/c/2e1f2d9a9bdbe12ee475c82a45ac46a278e8049a https://git.kernel.org/stable/c/7d271b798add90c6196539167c019d0817285cf0 https://git.kernel.org/stable/c/c45e53c27b78afd6c81fc25608003576f27b5735 https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3 https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a https://git.kernel.org/stable/c/5cd8af02b466e1beeae13e2de3dc58fcc • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: pci_iounmap(): Fix MMIO mapping leak The #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentally also guards iounmap(), which means MMIO mappings are leaked. Move the guard so we call iounmap() for MMIO mappings. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: pci_iounmap(): corrige la fuga de mapeo MMIO El #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentalmente también protege iounmap(), lo que significa que se filtraron los mapeos MMIO. Mueva la guardia para que llamemos a iounmap() para asignaciones MMIO. • https://git.kernel.org/stable/c/316e8d79a0959c302b0c462ab64b069599f10eef https://git.kernel.org/stable/c/5e4b23e7a7b33a1e56bfa3e5598138a2234d55b6 https://git.kernel.org/stable/c/6d21d0356aa44157a62e39c0d1a13d4c69a8d0c8 https://git.kernel.org/stable/c/b5d40f02e7222da032c2042aebcf2a07de9b342f https://git.kernel.org/stable/c/f3749345a9b7295dd071d0ed589634cb46364f77 https://git.kernel.org/stable/c/af280e137e273935f2e09f4d73169998298792ed https://git.kernel.org/stable/c/7626913652cc786c238e2dd7d8740b17d41b2637 •