Page 74 of 3230 results (0.016 seconds)

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

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 •

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

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 •

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

In the Linux kernel, the following vulnerability has been resolved: bpf: Check bloom filter map value size This patch adds a missing check to bloom filter creating, rejecting values above KMALLOC_MAX_SIZE. This brings the bloom map in line with many other map types. The lack of this protection can cause kernel crashes for value sizes that overflow int's. Such a crash was caught by syzkaller. The next patch adds more guard-rails at a lower level. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: Verificar el tamaño del valor del mapa del filtro de floración. • https://git.kernel.org/stable/c/fa6995eeb62e74b5a1480c73fb7b420c270784d3 https://git.kernel.org/stable/c/608e13706c8b6c658a0646f09ebced74ec367f7c https://git.kernel.org/stable/c/c418afb9bf23e2f2b76cb819601e4a5d9dbab42d https://git.kernel.org/stable/c/a8d89feba7e54e691ca7c4efc2a6264fa83f3687 •

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

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/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: -EPSS: 0%CPEs: 6EXPL: 0

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-&gt;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/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/msg00019.html •