CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2024-40903 – usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps
https://notcve.org/view.php?id=CVE-2024-40903
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps There could be a potential use-after-free case in tcpm_register_source_caps(). This could happen when: * new (say invalid) source caps are advertised * the existing source caps are unregistered * tcpm_register_source_caps() returns with an error as usb_power_delivery_register_capabilities() fails This causes port->partner_source_caps to hold on to the now freed source caps. Reset port->partner_source_caps value to NULL after unregistering existing source caps. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: arreglar el caso de use-after-free en tcpm_register_source_caps Podría haber un posible caso de use-after-free en tcpm_register_source_caps(). Esto podría suceder cuando: * se anuncian límites de fuente nuevos (por ejemplo, no válidos) * los límites de fuente existentes no están registrados * tcpm_register_source_caps() devuelve un error ya que usb_power_delivery_register_capabilities() falla Esto hace que port->partner_source_caps conserve los límites de fuente ahora liberados. Restablezca el valor de puerto->partner_source_caps a NULL después de cancelar el registro de los límites de origen existentes. • https://git.kernel.org/stable/c/cfcd544a9974c6b6fb37ca385146e4796dcaf66d https://git.kernel.org/stable/c/b16abab1fb645c4b7a86c357dc83a48cf21c2795 https://git.kernel.org/stable/c/230ecdf71a644c9c73e0e6735b33173074ae3f94 https://git.kernel.org/stable/c/931b5f302d6f7126dbd6879c42d3d6ca580be423 https://git.kernel.org/stable/c/4053696594d7235f3638d49a00cf0f289e4b36a3 https://git.kernel.org/stable/c/04c05d50fa79a41582f7bde8a1fd4377ae4a39e5 https://git.kernel.org/stable/c/6b67b652849faf108a09647c7fde9b179ef24e2b https://git.kernel.org/stable/c/e7e921918d905544500ca7a95889f8981 • CWE-416: Use After Free •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40902 – jfs: xattr: fix buffer overflow for invalid xattr
https://notcve.org/view.php?id=CVE-2024-40902
In the Linux kernel, the following vulnerability has been resolved: jfs: xattr: fix buffer overflow for invalid xattr When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jfs: xattr: corrige el desbordamiento del búfer para xattr no válido Cuando un tamaño de xattr no es el esperado, se imprime en el registro del kernel en formato hexadecimal como una forma de depuración. Pero cuando el tamaño de xattr es mayor que el tamaño esperado, imprimirlo puede provocar un acceso desde el final del búfer. Solucione todo esto restringiendo adecuadamente el tamaño del volcado hexadecimal de depuración en el registro del kernel. • https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0 https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7 https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123 https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69 https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40901 – scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory
https://notcve.org/view.php?id=CVE-2024-40901
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory There is a potential out-of-bounds access when using test_bit() on a single word. The test_bit() and set_bit() functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump: BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965 For full log, please look at [1]. Make the allocation at least the size of sizeof(unsigned long) so that set_bit() and test_bit() have sufficient room for read/write operations without overwriting unallocated memory. [1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/ • https://git.kernel.org/stable/c/c696f7b83edeac804e898952058089143f49ca0a https://git.kernel.org/stable/c/e9bce7c751f6d6c7be88c0bc081a66aaf61a23ee https://git.kernel.org/stable/c/19649e49a6df07cd2e03e0a11396fd3a99485ec2 https://git.kernel.org/stable/c/0081d2b3ae0a17a86b8cc0fa3c8bdc54e233ba16 https://git.kernel.org/stable/c/521f333e644c4246ca04a4fc4772edc53dd2a801 https://git.kernel.org/stable/c/46bab2bcd771e725ff5ca3a68ba68cfeac45676c https://git.kernel.org/stable/c/9079338c5a0d1f1fee34fb1c9e99b754efe414c5 https://git.kernel.org/stable/c/18abb5db0aa9b2d48f7037a88b41af2ee •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40900 – cachefiles: remove requests from xarray during flushing requests
https://notcve.org/view.php?id=CVE-2024-40900
In the Linux kernel, the following vulnerability has been resolved: cachefiles: remove requests from xarray during flushing requests Even with CACHEFILES_DEAD set, we can still read the requests, so in the following concurrency the request may be used after it has been freed: mount | daemon_thread1 | daemon_thread2 ------------------------------------------------------------ cachefiles_ondemand_init_object cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done) cachefiles_daemon_read cachefiles_ondemand_daemon_read // close dev fd cachefiles_flush_reqs complete(&REQ_A->done) kfree(REQ_A) xa_lock(&cache->reqs); cachefiles_ondemand_select_req req->msg.opcode != CACHEFILES_OP_READ // req use-after-free !!! xa_unlock(&cache->reqs); xa_destroy(&cache->reqs) Hence remove requests from cache->reqs when flushing them to avoid accessing freed requests. • https://git.kernel.org/stable/c/c8383054506c77b814489c09877b5db83fd4abf2 https://git.kernel.org/stable/c/9f13aacdd4ee9a7644b2a3c96d67113cd083c9c7 https://git.kernel.org/stable/c/50d0e55356ba5b84ffb51c42704126124257e598 https://git.kernel.org/stable/c/37e19cf86a520d65de1de9cb330415c332a40d19 https://git.kernel.org/stable/c/0fc75c5940fa634d84e64c93bfc388e1274ed013 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-40899 – cachefiles: fix slab-use-after-free in cachefiles_ondemand_get_fd()
https://notcve.org/view.php?id=CVE-2024-40899
In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix slab-use-after-free in cachefiles_ondemand_get_fd() We got the following issue in a fuzz test of randomly issuing the restore command: ================================================================== BUG: KASAN: slab-use-after-free in cachefiles_ondemand_daemon_read+0x609/0xab0 Write of size 4 at addr ffff888109164a80 by task ondemand-04-dae/4962 CPU: 11 PID: 4962 Comm: ondemand-04-dae Not tainted 6.8.0-rc7-dirty #542 Call Trace: kasan_report+0x94/0xc0 cachefiles_ondemand_daemon_read+0x609/0xab0 vfs_read+0x169/0xb50 ksys_read+0xf5/0x1e0 Allocated by task 626: __kmalloc+0x1df/0x4b0 cachefiles_ondemand_send_req+0x24d/0x690 cachefiles_create_tmpfile+0x249/0xb30 cachefiles_create_file+0x6f/0x140 cachefiles_look_up_object+0x29c/0xa60 cachefiles_lookup_cookie+0x37d/0xca0 fscache_cookie_state_machine+0x43c/0x1230 [...] Freed by task 626: kfree+0xf1/0x2c0 cachefiles_ondemand_send_req+0x568/0x690 cachefiles_create_tmpfile+0x249/0xb30 cachefiles_create_file+0x6f/0x140 cachefiles_look_up_object+0x29c/0xa60 cachefiles_lookup_cookie+0x37d/0xca0 fscache_cookie_state_machine+0x43c/0x1230 [...] ================================================================== Following is the process that triggers the issue: mount | daemon_thread1 | daemon_thread2 ------------------------------------------------------------ cachefiles_ondemand_init_object cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done) cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req cachefiles_ondemand_get_fd copy_to_user(_buffer, msg, n) process_open_req(REQ_A) ------ restore ------ cachefiles_ondemand_restore xas_for_each(&xas, req, ULONG_MAX) xas_set_mark(&xas, CACHEFILES_REQ_NEW); cachefiles_daemon_read cachefiles_ondemand_daemon_read REQ_A = cachefiles_ondemand_select_req write(devfd, ("copen %u,%llu", msg->msg_id, size)); cachefiles_ondemand_copen xa_erase(&cache->reqs, id) complete(&REQ_A->done) kfree(REQ_A) cachefiles_ondemand_get_fd(REQ_A) fd = get_unused_fd_flags file = anon_inode_getfile fd_install(fd, file) load = (void *)REQ_A->msg.data; load->fd = fd; // load UAF !!! This issue is caused by issuing a restore command when the daemon is still alive, which results in a request being processed multiple times thus triggering a UAF. So to avoid this problem, add an additional reference count to cachefiles_req, which is held while waiting and reading, and then released when the waiting and reading is over. Note that since there is only one reference count for waiting, we need to avoid the same request being completed multiple times, so we can only complete the request if it is successfully removed from the xarray. • https://git.kernel.org/stable/c/e73fa11a356ca0905c3cc648eaacc6f0f2d2c8b3 https://git.kernel.org/stable/c/1d902d9a3aa4f2a8bda698294e34be788be012fc https://git.kernel.org/stable/c/de3e26f9e5b76fc628077578c001c4a51bf54d06 https://git.kernel.org/stable/c/99e9c5bd27ddefa0f9db88625bf5e31c1e833d62 https://git.kernel.org/stable/c/a6de82765e12fb1201ab607f0d3ffe3309b30fc0 •