CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35832 – bcachefs: kvfree bch_fs::snapshots in bch2_fs_snapshots_exit
https://notcve.org/view.php?id=CVE-2024-35832
In the Linux kernel, the following vulnerability has been resolved: bcachefs: kvfree bch_fs::snapshots in bch2_fs_snapshots_exit bch_fs::snapshots is allocated by kvzalloc in __snapshot_t_mut. It should be freed by kvfree not kfree. Or umount will triger: [ 406.829178 ] BUG: unable to handle page fault for address: ffffe7b487148008 [ 406.830676 ] #PF: supervisor read access in kernel mode [ 406.831643 ] #PF: error_code(0x0000) - not-present page [ 406.832487 ] PGD 0 P4D 0 [ 406.832898 ] Oops: 0000 [#1] PREEMPT SMP PTI [ 406.833512 ] CPU: 2 PID: 1754 Comm: umount Kdump: loaded Tainted: G OE 6.7.0-rc7-custom+ #90 [ 406.834746 ] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 406.835796 ] RIP: 0010:kfree+0x62/0x140 [ 406.836197 ] Code: 80 48 01 d8 0f 82 e9 00 00 00 48 c7 c2 00 00 00 80 48 2b 15 78 9f 1f 01 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 56 9f 1f 01 <48> 8b 50 08 48 89 c7 f6 c2 01 0f 85 b0 00 00 00 66 90 48 8b 07 f6 [ 406.837810 ] RSP: 0018:ffffb9d641607e48 EFLAGS: 00010286 [ 406.838213 ] RAX: ffffe7b487148000 RBX: ffffb9d645200000 RCX: ffffb9d641607dc4 [ 406.838738 ] RDX: 000065bb00000000 RSI: ffffffffc0d88b84 RDI: ffffb9d645200000 [ 406.839217 ] RBP: ffff9a4625d00068 R08: 0000000000000001 R09: 0000000000000001 [ 406.839650 ] R10: 0000000000000001 R11: 000000000000001f R12: ffff9a4625d4da80 [ 406.840055 ] R13: ffff9a4625d00000 R14: ffffffffc0e2eb20 R15: 0000000000000000 [ 406.840451 ] FS: 00007f0a264ffb80(0000) GS:ffff9a4e2d500000(0000) knlGS:0000000000000000 [ 406.840851 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 406.841125 ] CR2: ffffe7b487148008 CR3: 000000018c4d2000 CR4: 00000000000006f0 [ 406.841464 ] Call Trace: [ 406.841583 ] <TASK> [ 406.841682 ] ? __die+0x1f/0x70 [ 406.841828 ] ? page_fault_oops+0x159/0x470 [ 406.842014 ] ? fixup_exception+0x22/0x310 [ 406.842198 ] ? exc_page_fault+0x1ed/0x200 [ 406.842382 ] ? • https://git.kernel.org/stable/c/56590678791119b9a655202e49898edfb9307271 https://git.kernel.org/stable/c/369acf97d6fd5da620d053d0f1878ffe32eff555 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52664 – net: atlantic: eliminate double free in error handling logic
https://notcve.org/view.php?id=CVE-2023-52664
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: atlantic: elimina double free en la lógica de manejo de errores El controlador tiene una fuga lógica en la asignación de datos del anillo/free, donde se podría llamar a aq_ring_free varias veces en el mismo anillo, si el sistema está bajo estrés y obtuve un error de asignación de memoria. Se utilizó un puntero de anillo como indicador de error, pero esto no es correcto ya que solo se asignan/desasignan datos de anillo. El anillo en sí es un miembro de la matriz. Cambiar las funciones de asignación de anillos para devolver el código de error directamente. • https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928 https://access.redhat.com/security/cve/CVE-2023-52664 https://bugzilla.redhat.com/show_bug.cgi?id=2281356 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35828 – wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
https://notcve.org/view.php?id=CVE-2024-35828
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer() In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer(). En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: libertas: arreglados algunas memleaks en lbs_allocate_cmd_buffer() En la declaración for de lbs_allocate_cmd_buffer(), si falló la asignación de cmdarray[i].cmdbuf, tanto cmdarray como cmdarray[i] Es necesario liberar ].cmdbuf. De lo contrario, habrá fugas de memoria en lbs_allocate_cmd_buffer(). • https://git.kernel.org/stable/c/876c9d3aeb989cf1961f2c228d309ba5dcfb1172 https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186 https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7 https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2 https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9 https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3 https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23ed •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35822 – usb: udc: remove warning when queue disabled ep
https://notcve.org/view.php?id=CVE-2024-35822
In the Linux kernel, the following vulnerability has been resolved: usb: udc: remove warning when queue disabled ep It is possible trigger below warning message from mass storage function, WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable. As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: udc: elimina la advertencia cuando la cola está deshabilitada ep Es posible que se active el siguiente mensaje de advertencia desde la función de almacenamiento masivo, ADVERTENCIA: CPU: 6 PID: 3839 en drivers/usb/gadget/udc /core.c:294 usb_ep_queue+0x7c/0x104 pc: usb_ep_queue+0x7c/0x104 lr: fsg_main_thread+0x494/0x1b3c La causa principal es que la función de almacenamiento masivo intenta poner en cola la solicitud desde el hilo principal, pero es posible que otro hilo ya deshabilite ep cuando la función se deshabilita. Como no hay ningún fallo de función en el controlador, para evitar el esfuerzo de corregir la advertencia, cambie WARN_ON_ONCE() en usb_ep_queue() a pr_debug(). • https://git.kernel.org/stable/c/2b002c308e184feeaeb72987bca3f1b11e5f70b8 https://git.kernel.org/stable/c/68d951880d0c52c7f13dcefb5501b69b8605ce8c https://git.kernel.org/stable/c/3e944ddc17c042945d983e006df7860687a8849a https://git.kernel.org/stable/c/df5cbb908f1687e8ab97e222a16b7890d5501acf https://git.kernel.org/stable/c/f74c5e0b54b02706d9a862ac6cddade30ac86bcf https://git.kernel.org/stable/c/99731076722eb7ed26b0c87c879da7bb71d24290 https://git.kernel.org/stable/c/36177c2595df12225b95ce74eb1ac77b43d5a58c https://git.kernel.org/stable/c/30511676eb54d480d014352bf784f0257 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35818 – LoongArch: Define the __io_aw() hook as mmiowb()
https://notcve.org/view.php?id=CVE-2024-35818
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Define the __io_aw() hook as mmiowb() Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says: "NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation." The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio. So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). • https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167 https://git.kernel.org/stable/c/d7d7c6cdea875be3b241d7d39873bb431db7154d https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0 https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb https://git.kernel.org/stable/c/9c68ece8b2a5c5ff9b2fcaea923dd73efeb174cd •