Page 141 of 4757 results (0.010 seconds)

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

29 May 2024 — In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes p... • https://git.kernel.org/stable/c/e1eaea46bb4020b38a141b84f88565d4603f8dd0 • CWE-125: Out-of-bounds Read CWE-787: Out-of-bounds Write •

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

29 May 2024 — In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs t... • https://git.kernel.org/stable/c/354e4aa391ed50a4d827ff6fc11e0667d0859b25 •

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

24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do that. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: n_gsm: requiere CAP_NET_ADMIN para adjuntar el ldisc N_GSM0710. Cualquier usuario sin privilegios puede adjuntar el ldisc N_GSM0710, pero de todos m... • https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

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

24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect() The free_rtllib() function frees the "dev" pointer so there is use after free on the next line. Re-arrange things to avoid that. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: staging: rtl8192e: Corrige el use after free en _rtl92e_pci_disconnect() La función free_rtllib() libera el puntero "dev" para que haya use after free en la siguiente línea. Reorganic... • https://git.kernel.org/stable/c/66898177e7e5486dc77a4ba742efa4e2e9e900a4 • CWE-416: Use After Free •

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

24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: proc/vmcore: fix clearing user buffer by properly using clear_user() To clear a user buffer we cannot simply use memset, we have to use clear_user(). With a virtio-mem device that registers a vmcore_cb and has some logically unplugged memory inside an added Linux memory block, I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdum... • https://git.kernel.org/stable/c/997c136f518c5debd63847e78e2a8694f56dcf90 • CWE-501: Trust Boundary Violation •

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

24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix kernel panic during drive powercycle test While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL. En el kernel de Linux, se resolvió la siguien... • https://git.kernel.org/stable/c/f92363d12359498f9a9960511de1a550f0ec41c2 •

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

24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release() For avoiding to slow down queue destroy, we don't call blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to cancel dispatch work in blk_release_queue(). However, this way has caused kernel oops[1], reported by Changhui. The log shows that scsi_device can be freed before running blk_release_queue(), which is expected too since scsi_device is rel... • https://git.kernel.org/stable/c/e03513f58919d9e2bc6df765ca2c9da863d03d90 •

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

24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux, a bug is reported: ================================================================== BUG: Unable to handle kernel data access on read at 0x80000800805b502c Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] Cal... • https://git.kernel.org/stable/c/faf0b2e5afe7dae072d2715763c7f992b612b628 •

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

24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, w... • https://git.kernel.org/stable/c/948968f8747650447c8f21c9fdba0e1973be040b • CWE-129: Improper Validation of Array Index •

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

24 May 2024 — In the Linux kernel, the following vulnerability has been resolved: net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the 'for' end, the 'k' is 8. At this time, the array 'lp->phy[8]' may be out of bound. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tulip: de4x5: soluciona el problema de que la matriz 'lp->phy[8]' puede estar fuera de límites En la línea 5001, si todos los ID de la... • https://git.kernel.org/stable/c/ec5bd0aef1cec96830d0c7e06d3597d9e786cc98 •