CVSS: 6.7EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36921 – wifi: iwlwifi: mvm: guard against invalid STA ID on removal
https://notcve.org/view.php?id=CVE-2024-36921
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: guard against invalid STA ID on removal Guard against invalid station IDs in iwl_mvm_mld_rm_sta_id as that would result in out-of-bounds array accesses. This prevents issues should the driver get into a bad state during error handling. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: iwlwifi: mvm: proteger contra ID de STA no válido al eliminarlo Proteger contra ID de estación no válidos en iwl_mvm_mld_rm_sta_id ya que eso daría como resultado accesos a la matriz fuera de los límites. Esto evita problemas en caso de que el controlador entre en mal estado durante el manejo de errores. An out-of-bounds memory access flaw was found in the Linux kernel’s Wireless WiFi Link Next-Gen AGN driver in how a user removes it. • https://git.kernel.org/stable/c/94f80a8ec15e238b78521f20f8afaed60521a294 https://git.kernel.org/stable/c/fab21d220017daa5fd8a3d788ff25ccfecfaae2f https://git.kernel.org/stable/c/17f64517bf5c26af56b6c3566273aad6646c3c4f https://access.redhat.com/security/cve/CVE-2024-36921 https://bugzilla.redhat.com/show_bug.cgi?id=2284513 • CWE-125: Out-of-bounds Read •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36920 – scsi: mpi3mr: Avoid memcpy field-spanning write WARNING
https://notcve.org/view.php?id=CVE-2024-36920
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Avoid memcpy field-spanning write WARNING When the "storcli2 show" command is executed for eHBA-9600, mpi3mr driver prints this WARNING message: memcpy: detected field-spanning write (size 128) of single field "bsg_reply_buf->reply_buf" at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1) WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr] The cause of the WARN is 128 bytes memcpy to the 1 byte size array "__u8 replay_buf[1]" in the struct mpi3mr_bsg_in_reply_buf. The array is intended to be a flexible length array, so the WARN is a false positive. To suppress the WARN, remove the constant number '1' from the array declaration and clarify that it has flexible length. Also, adjust the memory allocation size to match the change. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpi3mr: evitar escritura de extensión de campos de memcpy ADVERTENCIA Cuando se ejecuta el comando "storcli2 show" para eHBA-9600, el controlador mpi3mr imprime este mensaje de ADVERTENCIA: memcpy: extensión de campos detectada escriba (tamaño 128) de un solo campo "bsg_reply_buf->reply_buf" en drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (tamaño 1) ADVERTENCIA: CPU: 0 PID: 12760 en drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr] La causa de la ADVERTENCIA es 128 bytes de memoria en la matriz de tamaño de 1 byte "__u8 replay_buf[1]" en la estructura mpi3mr_bsg_in_reply_buf. La matriz está manipulada para ser una matriz de longitud flexible, por lo que WARN es un falso positivo. • https://git.kernel.org/stable/c/5f0266044dc611563539705bff0b3e1545fbb6aa https://git.kernel.org/stable/c/f09318244c6cafd10aca741b9c01e0a2c362d43a https://git.kernel.org/stable/c/4d2772324f43cf5674ac3dbe3f74a7e656396716 https://git.kernel.org/stable/c/429846b4b6ce9853e0d803a2357bb2e55083adf0 https://access.redhat.com/security/cve/CVE-2024-36920 https://bugzilla.redhat.com/show_bug.cgi?id=2284515 •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36919 – scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
https://notcve.org/view.php?id=CVE-2024-36919
In the Linux kernel, the following vulnerability has been resolved: scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required. This will suppress following BUG_ON(): [ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] __iommu_dma_free+0x96/0x100 [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc] [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc] [ 450.023103] process_one_work+0x1e8/0x3c0 [ 450.027581] worker_thread+0x50/0x3b0 [ 450.031669] ? • https://git.kernel.org/stable/c/468f3e3c15076338367b0945b041105b67cf31e3 https://git.kernel.org/stable/c/acd370c1fb86b7302c1cbb354a7c1cd9953768eb https://git.kernel.org/stable/c/ad498539dda0816aadef384ec117bfea304c75c3 https://git.kernel.org/stable/c/93aa5ccc44781bdfef1bf0bc4c2c292d45251312 https://git.kernel.org/stable/c/1150606d47d711d5bfdf329a1a96ed7027085936 https://git.kernel.org/stable/c/c885ab23206b1f1ba0731ffe7c9455c6a91db256 https://git.kernel.org/stable/c/ea50941cd8c9f0b12f38b73d3b1bfeca660dd342 https://git.kernel.org/stable/c/c214ed2a4dda35b308b0b28eed804d7ae • CWE-667: Improper Locking •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36917 – block: fix overflow in blk_ioctl_discard()
https://notcve.org/view.php?id=CVE-2024-36917
In the Linux kernel, the following vulnerability has been resolved: block: fix overflow in blk_ioctl_discard() There is no check for overflow of 'start + len' in blk_ioctl_discard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corrige el desbordamiento en blk_ioctl_discard() No hay verificación de desbordamiento de 'start + len' en blk_ioctl_discard(). La tarea bloqueada ocurre si envía un ioctl de descarte con el siguiente parámetro: start = 0x80000000000ff000, len = 0x8000000000fff000; Agregue la validación de desbordamiento ahora. • https://git.kernel.org/stable/c/d30a2605be9d5132d95944916e8f578fcfe4f976 https://git.kernel.org/stable/c/8a26198186e97ee5fc4b42fde82629cff8c75cd6 https://git.kernel.org/stable/c/e1d38cde2b7b0fbd1c48082e7a98c37d750af59b https://git.kernel.org/stable/c/507d526a98c355e6f3fb2c47aacad44a69784bee https://git.kernel.org/stable/c/22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 https://access.redhat.com/security/cve/CVE-2024-36917 https://bugzilla.redhat.com/show_bug.cgi?id=2284519 • CWE-190: Integer Overflow or Wraparound •
CVSS: 6.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36916 – blk-iocost: avoid out of bounds shift
https://notcve.org/view.php?id=CVE-2024-36916
In the Linux kernel, the following vulnerability has been resolved: blk-iocost: avoid out of bounds shift UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures. [ 186.556576] ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020 Call Trace: <IRQ> dump_stack_lvl+0x8f/0xe0 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 iocg_kick_delay+0x30b/0x310 ioc_timer_fn+0x2fb/0x1f80 __run_timer_base+0x1b6/0x250 ... Avoid that undefined behavior by simply taking the "delay = 0" branch if the shift is too large. I am not sure what the symptoms of an undefined value delay will be, but I suspect it could be more than a little annoying to debug. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-iocost: evita cambios fuera de los límites UBSAN detecta un comportamiento indefinido en blk-iocost, donde a veces iocg->delay se desplaza hacia la derecha en un número demasiado grande, lo que resulta en un estado indefinido. comportamiento en algunas arquitecturas. [186.556576] ------------[ cortar aquí ]------------ UBSAN: desplazamiento fuera de los límites en block/blk-iocost.c:1366 :23 exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'u64' (también conocido como 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: GSEN 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1 Nombre de hardware: Quanta Twin Lakes MP/Twin Lakes MP pasivo, BIOS F09_3A23 08/12/2020 Seguimiento de llamadas: dump_stack_lvl+0x8f/0xe0 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 iocg_kick_delay+0x30b/0x310 ioc_timer_fn+0x2fb/0x 1f80 __run_timer_base+0x1b6/0x250 ... Evitar ese comportamiento indefinido simplemente tomando la rama "retraso = 0" si el cambio es demasiado grande. No estoy seguro de cuáles serán los síntomas de un retraso de valor indefinido, pero sospecho que podría ser más que molesto depurarlo. • https://git.kernel.org/stable/c/7caa47151ab2e644dd221f741ec7578d9532c9a3 https://git.kernel.org/stable/c/62accf6c1d7b433752cb3591bba8967b7a801ad5 https://git.kernel.org/stable/c/844fc023e9f14a4fb1de5ae1eaefafd6d69c5fa1 https://git.kernel.org/stable/c/f6add0a6f78dc6360b822ca4b6f9f2f14174c8ca https://git.kernel.org/stable/c/ce0e99cae00e3131872936713b7f55eefd53ab86 https://git.kernel.org/stable/c/488dc6808cb8369685f18cee81e88e7052ac153b https://git.kernel.org/stable/c/beaa51b36012fad5a4d3c18b88a617aea7a9b96d https://lists.debian.org/debian-lts-announce/2024/06/ •