Page 198 of 2701 results (0.007 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: blktrace: Fix uaf in blk_trace access after removing by sysfs There is an use-after-free problem triggered by following process: P1(sda) P2(sdb) echo 0 > /sys/block/sdb/trace/enable blk_trace_remove_queue synchronize_rcu blk_trace_free relay_close rcu_read_lock __blk_add_trace trace_note_tsk (Iterate running_trace_list) relay_close_buf relay_destroy_buf kfree(buf) trace_note(sdb's bt) relay_reserve buf->offset <- nullptr deference (use-after-free) !!! rcu_read_unlock [ 502.714379] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 502.715260] #PF: supervisor read access in kernel mode [ 502.715903] #PF: error_code(0x0000) - not-present page [ 502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0 [ 502.717252] Oops: 0000 [#1] SMP [ 502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360 [ 502.732872] Call Trace: [ 502.733193] __blk_add_trace.cold+0x137/0x1a3 [ 502.733734] blk_add_trace_rq+0x7b/0xd0 [ 502.734207] blk_add_trace_rq_issue+0x54/0xa0 [ 502.734755] blk_mq_start_request+0xde/0x1b0 [ 502.735287] scsi_queue_rq+0x528/0x1140 ... [ 502.742704] sg_new_write.isra.0+0x16e/0x3e0 [ 502.747501] sg_ioctl+0x466/0x1100 Reproduce method: ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sda, BLKTRACESTART) ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sdb, BLKTRACESTART) echo 0 > /sys/block/sdb/trace/enable & // Add delay(mdelay/msleep) before kernel enters blk_trace_free() ioctl$SG_IO(/dev/sda, SG_IO, ...) // Enters trace_note_tsk() after blk_trace_free() returned // Use mdelay in rcu region rather than msleep(which may schedule out) Remove blk_trace from running_list before calling blk_trace_free() by sysfs if blk_trace is at Blktrace_running state. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blktrace: corrige uaf en el acceso a blk_trace después de eliminarlo mediante sysfs. Hay un problema de use after free desencadenado por el siguiente proceso: P1(sda) P2(sdb) echo 0 &gt; /sys /block/sdb/trace/enable blk_trace_remove_queue sincronizar_rcu blk_trace_free relé_cerrar rcu_read_lock __blk_add_trace trace_note_tsk (Iterar running_trace_list) relé_close_buf relé_destroy_buf kfree(buf) trace_note(sdb's bt) relé_reserve buf-&gt;offset &lt;- deferencia nullptr (uso-después) -gratis) !!! rcu_read_unlock [502.714379] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000010 [502.715260] #PF: acceso de lectura de supervisor en modo kernel [502.715903] #PF: error_code(0x0000) - página no presente [502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0 [ 502.717252] Vaya: 0000 [#1] SMP [ 502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360 [ 502.732872] Seguimiento de llamadas: [ 502.733193] 0x1a3 [502.733734] blk_add_trace_rq+ 0x7b/0xd0 [ 502.734207] blk_add_trace_rq_issue+0x54/0xa0 [ 502.734755] blk_mq_start_request+0xde/0x1b0 [ 502.735287] scsi_queue_rq+0x528/0x1140 ... [ 502.7427 04] sg_new_write.isra.0+0x16e/0x3e0 [ 502.747501] sg_ioctl+0x466/0x1100 Método de reproducción: ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sda, BLKTRACESTART) ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sdb , BLKTRACESTART) echo 0 &gt; /sys/block/sdb/trace/enable &amp; // Agrega retraso(mdelay/msleep) antes de que el kernel entre blk_trace_free() ioctl$SG_IO(/dev/sda, SG_IO, ...) // Entra trace_note_tsk() después de que blk_trace_free() regresara // Utilice mdelay en la región rcu en lugar de msleep (que puede programarse) Elimine blk_trace de running_list antes de llamar a blk_trace_free() mediante sysfs si blk_trace está en el estado Blktrace_running. • https://git.kernel.org/stable/c/c71a896154119f4ca9e89d6078f5f63ad60ef199 https://git.kernel.org/stable/c/488da313edf3abea7f7733efe011c96b23740ab5 https://git.kernel.org/stable/c/dacfd5e4d1142bfb3809aab3634a375f6f373269 https://git.kernel.org/stable/c/d56171d9360c0170c5c5f8f7e2362a2e999eca40 https://git.kernel.org/stable/c/677e362ba807f3aafe6f405c07e0b37244da5222 https://git.kernel.org/stable/c/ebb8d26d93c3ec3c7576c52a8373a2309423c069 https://git.kernel.org/stable/c/3815fe7371d2411ce164281cef40d9fc7b323dee https://git.kernel.org/stable/c/a5f8e86192612d0183047448d8bbe7918 • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: dma-debug: prevent an error message from causing runtime problems For some drivers, that use the DMA API. This error message can be reached several millions of times per second, causing spam to the kernel's printk buffer and bringing the CPU usage up to 100% (so, it should be rate limited). However, since there is at least one driver that is in the mainline and suffers from the error condition, it is more useful to err_printk() here instead of just rate limiting the error message (in hopes that it will make it easier for other drivers that suffer from this issue to be spotted). En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: dma-debug: evita que un mensaje de error cause problemas de tiempo de ejecución Para algunos controladores, que utilizan la API DMA. Este mensaje de error puede aparecer varios millones de veces por segundo, provocando spam en el búfer printk del kernel y elevando el uso de la CPU hasta el 100% (por lo tanto, debería tener una velocidad limitada). • https://git.kernel.org/stable/c/de4afec2d2946c92c62a15ab341c70b287289e6a https://git.kernel.org/stable/c/510e1a724ab1bf38150be2c1acabb303f98d0047 •

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

In the Linux kernel, the following vulnerability has been resolved: net: macb: fix use after free on rmmod plat_dev->dev->platform_data is released by platform_device_unregister(), use of pclk and hclk is a use-after-free. Since device unregister won't need a clk device we adjust the function call sequence to fix this issue. [ 31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci] [ 31.275563] Freed by task 306: [ 30.276782] platform_device_release+0x25/0x80 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: macb: corrige el use after free en rmmod plat_dev-&gt;dev-&gt;platform_data es publicado por platform_device_unregister(), el uso de pclk y hclk es un use after free. Dado que la cancelación del registro del dispositivo no necesitará un dispositivo clk, ajustamos la secuencia de llamada a la función para solucionar este problema. [31.261225] ERROR: KASAN: use after free en macb_remove+0x77/0xc6 [macb_pci] [31.275563] Liberado por la tarea 306: [30.276782] platform_device_release+0x25/0x80 • https://git.kernel.org/stable/c/a7d521cc726f30b8e679a6f36d04b18a8ab3c536 https://git.kernel.org/stable/c/46670fb832ee80943715df618632ca13c2e96f2b https://git.kernel.org/stable/c/1da750d1e2140ef43d64d17f301ff6f41b45541e https://git.kernel.org/stable/c/7721221e87d25c9840d9ca6b986dbdc410d5ce2b https://git.kernel.org/stable/c/4ad6f2d23b0f6ac0d3e5f3102a4256d1c86c90f5 https://git.kernel.org/stable/c/d82d5303c4c539db86588ffb5dc5b26c3f1513e8 •

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

In the Linux kernel, the following vulnerability has been resolved: afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and Linux's afs client switches between them when talking to a non-YFS server if the read size, the file position or the sum of the two have the upper 32 bits set of the 64-bit value. This is a problem, however, since the file position and length fields of FS.FetchData are *signed* 32-bit values. Fix this by capturing the capability bits obtained from the fileserver when it's sent an FS.GetCapabilities RPC, rather than just discarding them, and then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be used to decide whether to use FS.FetchData or FS.FetchData64 - and also FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to switch on the parameter values. This capabilities flag could also be used to limit the maximum size of the file, but all servers must be checked for that. Note that the issue does not exist with FS.StoreData - that uses *unsigned* 32-bit values. It's also not a problem with Auristor servers as its YFS.FetchData64 op uses unsigned 64-bit values. This can be tested by cloning a git repo through an OpenAFS client to an OpenAFS server and then doing "git status" on it from a Linux afs client[1]. Provided the clone has a pack file that's in the 2G-4G range, the git status will show errors like: error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index This can be observed in the server's FileLog with something like the following appearing: Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001 Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866 ... Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5 Note the file position of 18446744071815340032. This is the requested file position sign-extended. • https://git.kernel.org/stable/c/b9b1f8d5930a813879278d0cbfc8c658d6a038dc https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97 https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Update intermediate power state for SI Update the current state as boot state during dpm initialization. During the subsequent initialization, set_power_state gets called to transition to the final power state. set_power_state refers to values from the current state and without current state populated, it could result in NULL pointer dereference. For ex: on platforms where PCI speed change is supported through ACPI ATCS method, the link speed of current state needs to be queried before deciding on changing to final power state's link speed. The logic to query ATCS-support was broken on certain platforms. The issue became visible when broken ATCS-support logic got fixed with commit f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)"). Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Actualizar el estado de energía intermedio para SI. Actualiza el estado actual como estado de arranque durante la inicialización de dpm. Durante la inicialización posterior, se llama a set_power_state para realizar la transición al estado de energía final. set_power_state se refiere a valores del estado actual y sin el estado actual poblado, podría resultar en una desreferencia del puntero NULL. • https://git.kernel.org/stable/c/68d4fbe6220cd1f3d07cab0a4901e62f8c12cc68 https://git.kernel.org/stable/c/06a18e64256f7aecb5a27df02faa3568fcd3c105 https://git.kernel.org/stable/c/ab39d3cef526ba09c4c6923b4cd7e6ec1c5d4faa •