CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48770 – bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack()
https://notcve.org/view.php?id=CVE-2022-48770
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: 0CVE-2022-48769 – efi: runtime: avoid EFIv2 runtime services on Apple x86 machines
https://notcve.org/view.php?id=CVE-2022-48769
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: 0CVE-2022-48768 – tracing/histogram: Fix a potential memory leak for kstrdup()
https://notcve.org/view.php?id=CVE-2022-48768
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 •
CVSS: 5.3EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48767 – ceph: properly put ceph_string reference after async create attempt
https://notcve.org/view.php?id=CVE-2022-48767
In the Linux kernel, the following vulnerability has been resolved: ceph: properly put ceph_string reference after async create attempt The reference acquired by try_prep_async_create is currently leaked. Ensure we put it. • https://git.kernel.org/stable/c/9a8d03ca2e2c334d08ee91a3e07dcce31a02fdc6 https://git.kernel.org/stable/c/e7be12ca7d3947765b0d7c1c7e0537e748da993a https://git.kernel.org/stable/c/36d433ae3242aa714176378850e6d1a5a3e78f18 https://git.kernel.org/stable/c/a0c22e970cd78b81c94691e6cb09713e8074d580 https://git.kernel.org/stable/c/932a9b5870d38b87ba0a9923c804b1af7d3605b9 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48766 – drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.
https://notcve.org/view.php?id=CVE-2022-48766
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU. Mirrors the logic for dcn30. Cue lots of WARNs and some kernel panics without this fix. • https://git.kernel.org/stable/c/456ba2433844a6483cc4c933aa8f43d24575e341 https://git.kernel.org/stable/c/25f1488bdbba63415239ff301fe61a8546140d9f •