Page 124 of 2830 results (0.034 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: peci: cpu: Fix use-after-free in adev_release() When auxiliary_device_add() returns an error, auxiliary_device_uninit() is called, which causes refcount for device to be decremented and .release callback will be triggered. Because adev_release() re-calls auxiliary_device_uninit(), it will cause use-after-free: [ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15 [ 1269.464007] refcount_t: underflow; use-after-free. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: peci: cpu: corrige use-after-free en adev_release() Cuando auxiliar_device_add() devuelve un error, se llama a auxiliar_device_uninit(), lo que hace que se disminuya el recuento del dispositivo y . Se activará la devolución de llamada de liberación. Debido a que adev_release() vuelve a llamar a auxiliar_device_uninit(), provocará use-after-free: [1269.455172] ADVERTENCIA: CPU: 0 PID: 14267 en lib/refcount.c:28 refcount_warn_saturate+0x110/0x15 [1269.464007] refcount_t: underflow ; use-after-free. • https://git.kernel.org/stable/c/c87f1f99e26ea4ae08cabe753ae98e5626bdba89 https://git.kernel.org/stable/c/1c11289b34ab67ed080bbe0f1855c4938362d9cf • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: media: ttpci: fix two memleaks in budget_av_attach When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: ttpci: corrige dos fugas de mem en Budget_av_attach Cuando fallan saa7146_register_device y saa7146_vv_init, Budget_av_attach debería liberar los recursos que asigna, como lo hace el manejo de errores de ttpci_budget_init. Además, hay dos comentarios fijos que se refieren a dichas desasignaciones. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/af37aed04997e644f7e1b52b696b62dcae3cc016 https://git.kernel.org/stable/c/910363473e4bf97da3c350e08d915546dd6cc30b https://git.kernel.org/stable/c/24e51d6eb578b82ff292927f14b9f5ec05a46beb https://git.kernel.org/stable/c/55ca0c7eae8499bb96f4e5d9b26af95e89c4e6a0 https://git.kernel.org/stable/c/7393c681f9aa05ffe2385e8716989565eed2fe06 https://git.kernel.org/stable/c/1597cd1a88cfcdc4bf8b1b44cd458fed9a5a5d63 https://git.kernel.org/stable/c/656b8cc123d7635dd399d9f02594f27aa •

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

In the Linux kernel, the following vulnerability has been resolved: nouveau: lock the client object tree. It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings. 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555] <TASK> [ 4562.099573] ? die_addr+0x36/0x90 [ 4562.099583] ? exc_general_protection+0x246/0x4a0 [ 4562.099593] ? • https://git.kernel.org/stable/c/6887314f5356389fc219b8152e951ac084a10ef7 https://git.kernel.org/stable/c/96c8751844171af4b3898fee3857ee180586f589 https://git.kernel.org/stable/c/b7cc4ff787a572edf2c55caeffaa88cd801eb135 https://access.redhat.com/security/cve/CVE-2024-27062 https://bugzilla.redhat.com/show_bug.cgi?id=2278387 •

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

In the Linux kernel, the following vulnerability has been resolved: USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer. Protect against this possibility by refusing to bind to the device if either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: almacenamiento-usb: evita el error de división por 0 en isd200_ata_command El subcontrolador isd200 en almacenamiento-usb utiliza los valores HEADS y SECTORES en la información de ID de ATA para calcular el cilindro y valores principales al crear un CDB para comandos LEER o ESCRIBIR. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/9968c701cba7eda42e5f0052b040349d6222ae34 https://git.kernel.org/stable/c/eb7b01ca778170654e1c76950024270ba74b121f https://git.kernel.org/stable/c/284fb1003d5da111019b9e0bf99b084fd71ac133 https://git.kernel.org/stable/c/6c1f36d92c0a8799569055012665d2bb066fb964 https://git.kernel.org/stable/c/f42ba916689f5c7b1642092266d2f53cf527aaaa https://git.kernel.org/stable/c/871fd7b10b56d280990b7e754f43d888382ca325 https://git.kernel.org/stable/c/3a67d4ab9e730361d183086dfb0ddd8c6 •

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

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend When the system is suspended while audio is active, the sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during suspend the DSP is turned off, streams will be re-started after resume. If the firmware crashes during while audio is running (or when we reset the stream before suspend) then the sof_ipc4_set_multi_pipeline_state() will fail with IPC error and the state change is interrupted. This will cause misalignment between the kernel and firmware state on next DSP boot resulting errors returned by firmware for IPC messages, eventually failing the audio resume. On stream close the errors are ignored so the kernel state will be corrected on the next DSP boot, so the second boot after the DSP panic. If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then state parameter is SOF_IPC4_PIPE_RESET and only in this case. Treat a forced pipeline reset similarly to how we treat a pcm_free by ignoring error on state sending to allow the kernel's state to be consistent with the state the firmware will have after the next boot. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: SOF: ipc4-pcm: workaround para firmware bloqueado en suspensión del sistema Cuando el sistema se suspende mientras el audio está activo, se invoca sof_ipc4_pcm_hw_free() para restablecer las canalizaciones desde durante la suspensión el DSP está apagado, las transmisiones se reiniciarán después de reanudarse. Si el firmware falla mientras se ejecuta el audio (o cuando reiniciamos la transmisión antes de suspenderla), entonces sof_ipc4_set_multi_pipeline_state() fallará con un error de IPC y se interrumpirá el cambio de estado. Esto provocará una desalineación entre el estado del kernel y del firmware en el siguiente arranque del DSP, lo que provocará errores devueltos por el firmware para los mensajes IPC, lo que eventualmente provocará un error en la reanudación del audio. Al cerrar la transmisión, los errores se ignoran, por lo que el estado del kernel se corregirá en el siguiente inicio del DSP, es decir, en el segundo inicio después del pánico del DSP. • https://git.kernel.org/stable/c/3cac6eebea9b4bc5f041e157e45c76e212ad6759 https://git.kernel.org/stable/c/d153e8b154f9746ac969c85a4e6474760453647c https://git.kernel.org/stable/c/c40aad7c81e5fba34b70123ed7ce3397fa62a4d2 •