CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26842 – scsi: ufs: core: Fix shift issue in ufshcd_clear_cmd()
https://notcve.org/view.php?id=CVE-2024-26842
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix shift issue in ufshcd_clear_cmd() When task_tag >= 32 (in MCQ mode) and sizeof(unsigned int) == 4, 1U << task_tag will out of bounds for a u32 mask. Fix this up to prevent SHIFT_ISSUE (bitwise shifts that are out of bounds for their data type). [name:debug_monitors&]Unexpected kernel BRK exception at EL1 [name:traps&]Internal error: BRK handler: 00000000f2005514 [#1] PREEMPT SMP [name:mediatek_cpufreq_hw&]cpufreq stop DVFS log done [name:mrdump&]Kernel Offset: 0x1ba5800000 from 0xffffffc008000000 [name:mrdump&]PHYS_OFFSET: 0x80000000 [name:mrdump&]pstate: 22400005 (nzCv daif +PAN -UAO) [name:mrdump&]pc : [0xffffffdbaf52bb2c] ufshcd_clear_cmd+0x280/0x288 [name:mrdump&]lr : [0xffffffdbaf52a774] ufshcd_wait_for_dev_cmd+0x3e4/0x82c [name:mrdump&]sp : ffffffc0081471b0 <snip> Workqueue: ufs_eh_wq_0 ufshcd_err_handler Call trace: dump_backtrace+0xf8/0x144 show_stack+0x18/0x24 dump_stack_lvl+0x78/0x9c dump_stack+0x18/0x44 mrdump_common_die+0x254/0x480 [mrdump] ipanic_die+0x20/0x30 [mrdump] notify_die+0x15c/0x204 die+0x10c/0x5f8 arm64_notify_die+0x74/0x13c do_debug_exception+0x164/0x26c el1_dbg+0x64/0x80 el1h_64_sync_handler+0x3c/0x90 el1h_64_sync+0x68/0x6c ufshcd_clear_cmd+0x280/0x288 ufshcd_wait_for_dev_cmd+0x3e4/0x82c ufshcd_exec_dev_cmd+0x5bc/0x9ac ufshcd_verify_dev_init+0x84/0x1c8 ufshcd_probe_hba+0x724/0x1ce0 ufshcd_host_reset_and_restore+0x260/0x574 ufshcd_reset_and_restore+0x138/0xbd0 ufshcd_err_handler+0x1218/0x2f28 process_one_work+0x5fc/0x1140 worker_thread+0x7d8/0xe20 kthread+0x25c/0x468 ret_from_fork+0x10/0x20 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: ufs: core: solucione el problema de cambio en ufshcd_clear_cmd() Cuando task_tag >= 32 (en modo MCQ) y sizeof(unsigned int) == 4, 1U << task_tag será fuera de los límites para una máscara u32. Solucione esto para evitar SHIFT_ISSUE (desplazamientos bit a bit que están fuera de los límites de su tipo de datos). [nombre:debug_monitors&]Excepción inesperada de BRK del kernel en EL1 [nombre:traps&]Error interno: controlador BRK: 00000000f2005514 [#1] PREEMPT SMP [nombre:mediatek_cpufreq_hw&]cpufreq detiene el registro DVFS hecho [nombre:mrdump&]Kernel Offset: 0x1ba5800000 de 0xffffffc0 08000000 [nombre:mrdump&]PHYS_OFFSET: 0x80000000 [nombre:mrdump&]pstate: 22400005 (nzCv daif +PAN -UAO) [nombre:mrdump&]pc: [0xffffffdbaf52bb2c] ufshcd_clear_cmd+0x280/0x288 [nombre:mrdump&]lr: [0xffffffdbaf52 a774] ufshcd_wait_for_dev_cmd +0x3e4/0x82c [nombre:mrdump&]sp: ffffffc0081471b0 Cola de trabajo: ufs_eh_wq_0 ufshcd_err_handler Rastreo de llamadas: dump_backtrace+0xf8/0x144 show_stack+0x18/0x24 dump_stack_lvl+0x78/0x9c dump_stack+0x1 8/0x44 mrdump_common_die+0x254/0x480 [mrdump] ipanic_die+0x20/0x30 [mrdump] notify_die+0x15c/0x204 die+0x10c/0x5f8 arm64_notify_die+0x74/0x13c do_debug_exception+0x164/0x26c el1_dbg+0x64/0x80 el1h_64_sync_handler+0x3c/0x90 el 1h_64_sync+0x68/0x6c ufshcd_clear_cmd+0x280/0x288 ufshcd_wait_for_dev_cmd+ 0x3e4/0x82c ufshcd_exec_dev_cmd+0x5bc/0x9ac ufshcd_verify_dev_init+0x84/0x1c8 ufshcd_probe_hba+0x724/0x1ce0 ufshcd_host_reset_and_restore+0x260/0x574 ufshcd_reset_and_restore+0x13 8/0xbd0 ufshcd_err_handler+0x1218/0x2f28 proceso_one_work+0x5fc/0x1140 trabajador_thread+0x7d8/0xe20 kthread+0x25c/0x468 ret_from_fork+ 0x10/0x20 • https://git.kernel.org/stable/c/7ac9e18f5d66087cd22751c5c5bf0090eb0038fe https://git.kernel.org/stable/c/a992425d18e5f7c48931121993c6c69426f2a8fb https://git.kernel.org/stable/c/b513d30d59bb383a6a5d6b533afcab2cee99a8f8 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26840 – cachefiles: fix memory leak in cachefiles_add_cache()
https://notcve.org/view.php?id=CVE-2024-26840
In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix memory leak in cachefiles_add_cache() The following memory leak was reported after unbinding /dev/cachefiles: ================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370 [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0 [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120 [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0 [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520 [<ffffffff8ebc5069>] ksys_write+0x69/0xf0 [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140 [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ================================================================== Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: corrige la pérdida de memoria en cachefiles_add_cache() Se informó la siguiente pérdida de memoria después de desvincular /dev/cachefiles: ================= ==================================================== objeto sin referencia 0xffff9b674176e3c0 (tamaño 192): comm "cachefilesd2", pid 680, jiffies 4294881224 volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc ea38a44b): [ ] kmem_cache_alloc+0x2d5/0x370 [] prepare_creds+0x26/0x2e0 [] cachefiles_determine_cache_security+0x1f/0x120 [] cachefiles_add_cache+0x13c/0x 3a0 [] cachefiles_daemon_write+0x146/0x1c0 [ ] vfs_write+0xcb/0x520 [] ksys_write+0x69/0xf0 [] do_syscall_64+0x72/0x140 [] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 =============== ==================================================== == Coloque el recuento de referencias de cache_cred en cachefiles_daemon_unbind() para solucionar el problema. Y también coloque cache_cred en la rama de error cachefiles_add_cache() para evitar pérdidas de memoria. • https://git.kernel.org/stable/c/9ae326a69004dea8af2dae4fde58de27db700a8d https://git.kernel.org/stable/c/cb5466783793e66272624cf71925ae1d1ba32083 https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285 https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8 https://git.kernel.org/stable/c/94965be37add0983672e48ecb33cdbda92b62579 https://git.kernel.org/stable/c/8b218e2f0a27a9f09428b1847b4580640b9d1e58 https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3 https://git.kernel.org/stable/c/9cac69912052a4def571fedf1cb9bb4ec • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26830 – i40e: Do not allow untrusted VF to remove administratively set MAC
https://notcve.org/view.php?id=CVE-2024-26830
In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: No permitir que VF que no es de confianza elimine la MAC configurada administrativamente. Actualmente, cuando PF configura administrativamente la dirección MAC de VF y el VF se desactiva (VF intenta eliminar todas las MAC), entonces la MAC se eliminado de los filtros MAC y el MAC VF primario se pone a cero. No permita que VF que no es de confianza elimine la MAC principal cuando PF la configuró administrativamente. Reproductor: 1) Crear VF 2) Configurar la interfaz VF 3) Configurar administrativamente la MAC del VF 4) Colocar la interfaz VF [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@ host ~]# enlace ip establecido enp2s0f0v0 up [root@host ~]# enlace ip establecido enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# enlace ip show enp2s0f0 23: enp2s0f0: < BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq estado Modo UP DEFAULT grupo predeterminado qlen 1000 enlace/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 enlace/ ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, verificación de suplantación de identidad activada, estado de enlace automático, confianza desactivada [root@host ~]# enlace IP configurado enp2s0f0v0 inactivo [raíz @host ~]# ip link show enp2s0f0 23: enp2s0f0: mtu 1500 qdisc mq state Modo UP DEFAULT grupo predeterminado qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff :ff:ff:ff:ff:ff vf 0 enlace/éter 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, verificación de suplantación de identidad activada, estado de enlace automático, confianza desactivada A flaw was found in Intel network adapters in the Linux kernel, where untrusted virtualized network interfaces can remove MAC addresses set by the system. This flaw allows an attacker with sufficient privileges to cause a denial of service. • https://git.kernel.org/stable/c/700bbf6c1f9e4ab055528d5ab4ac5815fe4a6c1b https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893 https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404 https://git.kernel.org/stable/c/d250a81ba813a93563be68072c563aa1e346346d https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc https://access.redhat.com/security/cve/CVE-2024-26830 https://bugzilla.redhat.com/show_bug.cgi?id=2275596 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26825 – nfc: nci: free rx_data_reassembly skb on NCI device cleanup
https://notcve.org/view.php?id=CVE-2024-26825
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free rx_data_reassembly skb on NCI device cleanup rx_data_reassembly skb is stored during NCI data exchange for processing fragmented packets. It is dropped only when the last fragment is processed or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received. However, the NCI device may be deallocated before that which leads to skb leak. As by design the rx_data_reassembly skb is bound to the NCI device and nothing prevents the device to be freed before the skb is processed in some way and cleaned, free it on the NCI device cleanup. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: nci: rx_data_reassembly skb gratuito en la limpieza del dispositivo NCI rx_data_reassembly skb se almacena durante el intercambio de datos NCI para procesar paquetes fragmentados. Se elimina solo cuando se procesa el último fragmento o cuando se recibe un paquete NTF con el código de operación NCI_OP_RF_DEACTIVATE_NTF. Sin embargo, el dispositivo NCI puede desasignarse antes de lo que provoca una fuga de skb. • https://git.kernel.org/stable/c/6a2968aaf50c7a22fced77a5e24aa636281efca8 https://git.kernel.org/stable/c/7e9a8498658b398bf11b8e388005fa54e40aed81 https://git.kernel.org/stable/c/71349abe3aba7fedcab5b3fcd7aa82371fb5ccbf https://git.kernel.org/stable/c/2f6d16f0520d6505241629ee2f5c131b547d5f9d https://git.kernel.org/stable/c/471c9ede8061357b43a116fa692e70d91941ac23 https://git.kernel.org/stable/c/5c0c5ffaed73cbae6c317374dc32ba6cacc60895 https://git.kernel.org/stable/c/16d3f507b0fa70453dc54550df093d6e9ac630c1 https://git.kernel.org/stable/c/a3d90fb5c23f29ba59c04005ae76c5228 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52642 – media: rc: bpf attach/detach requires write permission
https://notcve.org/view.php?id=CVE-2023-52642
In the Linux kernel, the following vulnerability has been resolved: media: rc: bpf attach/detach requires write permission Note that bpf attach/detach also requires CAP_NET_ADMIN. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: rc: bpf adjunto/detach requiere permiso de escritura. Tenga en cuenta que bpf adjunto/detach también requiere CAP_NET_ADMIN. • https://git.kernel.org/stable/c/93d8109bf182510629bbefc8cd45296d2393987f https://git.kernel.org/stable/c/d98210108e7b2ff64b332b0a3541c8ad6a0617b0 https://git.kernel.org/stable/c/9f6087851ec6dce5b15f694aeaf3e8ec8243224e https://git.kernel.org/stable/c/93136132d1b5792bf44151e3494ae3691cd738e8 https://git.kernel.org/stable/c/caf2da1d4562de4e35eedec0be2b7f1ee25d83be https://git.kernel.org/stable/c/6a9d552483d50953320b9d3b57abdee8d436f23f https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •