Page 216 of 4169 results (0.020 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: isdn: cpai: check ctr->cnr to avoid array index out of bound The cmtp_add_connection() would add a cmtp session to a controller and run a kernel thread to process cmtp. __module_get(THIS_MODULE); session->task = kthread_run(cmtp_session, session, "kcmtpd_ctr_%d", session->num); During this process, the kernel thread would call detach_capi_ctr() to detach a register controller. if the controller was not attached yet, detach_capi_ctr() would trigger an array-index-out-bounds bug. [ 46.866069][ T6479] UBSAN: array-index-out-of-bounds in drivers/isdn/capi/kcapi.c:483:21 [ 46.867196][ T6479] index -1 is out of range for type 'capi_ctr *[32]' [ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted 5.15.0-rc2+ #8 [ 46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [ 46.870107][ T6479] Call Trace: [ 46.870473][ T6479] dump_stack_lvl+0x57/0x7d [ 46.870974][ T6479] ubsan_epilogue+0x5/0x40 [ 46.871458][ T6479] __ubsan_handle_out_of_bounds.cold+0x43/0x48 [ 46.872135][ T6479] detach_capi_ctr+0x64/0xc0 [ 46.872639][ T6479] cmtp_session+0x5c8/0x5d0 [ 46.873131][ T6479] ? __init_waitqueue_head+0x60/0x60 [ 46.873712][ T6479] ? cmtp_add_msgpart+0x120/0x120 [ 46.874256][ T6479] kthread+0x147/0x170 [ 46.874709][ T6479] ? set_kthread_struct+0x40/0x40 [ 46.875248][ T6479] ret_from_fork+0x1f/0x30 [ 46.875773][ T6479] • https://git.kernel.org/stable/c/e8b8de17e164c9f1b7777f1c6f99d05539000036 https://git.kernel.org/stable/c/24219a977bfe3d658687e45615c70998acdbac5a https://git.kernel.org/stable/c/9b6b2db77bc3121fe435f1d4b56e34de443bec75 https://git.kernel.org/stable/c/7d91adc0ccb060ce564103315189466eb822cc6a https://git.kernel.org/stable/c/285e9210b1fab96a11c0be3ed5cea9dd48b6ac54 https://git.kernel.org/stable/c/7f221ccbee4ec662e2292d490a43ce6c314c4594 https://git.kernel.org/stable/c/cc20226e218a2375d50dd9ac14fb4121b43375ff https://git.kernel.org/stable/c/1f3e2e97c003f80c4b087092b225c8787 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix stale file descriptors on failed usercopy A failing usercopy of the fence_rep object will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded. • https://git.kernel.org/stable/c/c906965dee22d5e95d0651759ba107b420212a9f https://git.kernel.org/stable/c/e8d092a62449dcfc73517ca43963d2b8f44d0516 https://git.kernel.org/stable/c/0008a0c78fc33a84e2212a7c04e6b21a36ca6f4d https://git.kernel.org/stable/c/84b1259fe36ae0915f3d6ddcea6377779de48b82 https://git.kernel.org/stable/c/ae2b20f27732fe92055d9e7b350abc5cdf3e2414 https://git.kernel.org/stable/c/6066977961fc6f437bc064f628cf9b0e4571c56c https://git.kernel.org/stable/c/1d833b27fb708d6fdf5de9f6b3a8be4bd4321565 https://git.kernel.org/stable/c/a0f90c8815706981c483a652a6aefca51 • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack() task_pt_regs() can return NULL on powerpc for kernel threads. This is then used in __bpf_get_stack() to check for user mode, resulting in a kernel oops. Guard against this by checking return value of task_pt_regs() before trying to obtain the call chain. • https://git.kernel.org/stable/c/fa28dcb82a38f8e3993b0fae9106b1a80b59e4f0 https://git.kernel.org/stable/c/ff6bdc205fd0a83bd365405d4e31fb5905826996 https://git.kernel.org/stable/c/0bcd484587b3b3092e448d27dc369e347e1810c3 https://git.kernel.org/stable/c/b82ef4985a6d05e80f604624332430351df7b79a https://git.kernel.org/stable/c/b992f01e66150fc5e90be4a96f5eb8e634c8249e •

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

In the Linux kernel, the following vulnerability has been resolved: efi: runtime: avoid EFIv2 runtime services on Apple x86 machines Aditya reports [0] that his recent MacbookPro crashes in the firmware when using the variable services at runtime. The culprit appears to be a call to QueryVariableInfo(), which we did not use to call on Apple x86 machines in the past as they only upgraded from EFI v1.10 to EFI v2.40 firmware fairly recently, and QueryVariableInfo() (along with UpdateCapsule() et al) was added in EFI v2.00. The only runtime service introduced in EFI v2.00 that we actually use in Linux is QueryVariableInfo(), as the capsule based ones are optional, generally not used at runtime (all the LVFS/fwupd firmware update infrastructure uses helper EFI programs that invoke capsule update at boot time, not runtime), and not implemented by Apple machines in the first place. QueryVariableInfo() is used to 'safely' set variables, i.e., only when there is enough space. This prevents machines with buggy firmwares from corrupting their NVRAMs when they run out of space. Given that Apple machines have been using EFI v1.10 services only for the longest time (the EFI v2.0 spec was released in 2006, and Linux support for the newly introduced runtime services was added in 2011, but the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only), let's avoid the EFI v2.0 ones on all Apple x86 machines. [0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/ • https://git.kernel.org/stable/c/b0f1cc093bc2493ac259c53766fd2b800e085807 https://git.kernel.org/stable/c/3df52448978802ae15dcebf66beba1029df957b4 https://git.kernel.org/stable/c/a4085859411c825c321c9b55b8a9dc5a128a6684 https://git.kernel.org/stable/c/f5390cd0b43c2e54c7cf5506c7da4a37c5cef746 •

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

In the Linux kernel, the following vulnerability has been resolved: tracing/histogram: Fix a potential memory leak for kstrdup() kfree() is missing on an error path to free the memory allocated by kstrdup(): p = param = kstrdup(data->params[i], GFP_KERNEL); So it is better to free it via kfree(p). • https://git.kernel.org/stable/c/38b67e60b6b582e81f9db1b2e7176cbbfbd3e574 https://git.kernel.org/stable/c/d380dcde9a07ca5de4805dee11f58a98ec0ad6ff https://git.kernel.org/stable/c/c78a2baf5e1fe1b38121d6b54bab77ccb81a1a86 https://git.kernel.org/stable/c/8a8878ebb596281f50fc0b9a6e1f23f0d7f154e8 https://git.kernel.org/stable/c/d71b06aa995007eafd247626d0669b9364c42ad7 https://git.kernel.org/stable/c/e33fa4a46ee22de88a700e2e3d033da8214a5175 https://git.kernel.org/stable/c/df86e2fe808c3536a9dba353cc2bebdfea00d0cf https://git.kernel.org/stable/c/e629e7b525a179e29d53463d992bdee75 •