CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49890 – drm/amd/pm: ensure the fw_info is not null before using it
https://notcve.org/view.php?id=CVE-2024-49890
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity. • https://git.kernel.org/stable/c/29f388945770bd0a6c82711436b2bc98b0dfac92 https://git.kernel.org/stable/c/9550d8d6f19fac7623f044ae8d9503825b325497 https://git.kernel.org/stable/c/fd5f4ac1a986f0e7e9fa019201b5890554f87bcf https://git.kernel.org/stable/c/b511474f49588cdca355ebfce54e7eddbf7b75a5 https://git.kernel.org/stable/c/8adf4408d482faa51b2c14e60bfd9946ec1911a4 https://git.kernel.org/stable/c/016bf0294b401246471c6710c6bf9251616228b6 https://git.kernel.org/stable/c/186fb12e7a7b038c2710ceb2fb74068f1b5d55a4 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49889 – ext4: avoid use-after-free in ext4_ext_show_leaf()
https://notcve.org/view.php?id=CVE-2024-49889
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality. • https://git.kernel.org/stable/c/b0cb4561fc4284d04e69c8a66c8504928ab2484e https://git.kernel.org/stable/c/4999fed877bb64e3e7f9ab9996de2ca983c41928 https://git.kernel.org/stable/c/2eba3b0cc5b8de624918d21f32b5b8db59a90b39 https://git.kernel.org/stable/c/34b2096380ba475771971a778a478661a791aa15 https://git.kernel.org/stable/c/8b114f2cc7dd5d36729d040b68432fbd0f0a8868 https://git.kernel.org/stable/c/d483c7cc1796bd6a80e7b3a8fd494996260f6b67 https://git.kernel.org/stable/c/4e2524ba2ca5f54bdbb9e5153bea00421ef653f5 •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49888 – bpf: Fix a sdiv overflow issue
https://notcve.org/view.php?id=CVE-2024-49888
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when ! • https://git.kernel.org/stable/c/ec0e2da95f72d4a46050a4d994e4fe471474fd80 https://git.kernel.org/stable/c/4902a6a0dc593c82055fc8c9ada371bafe26c9cc https://git.kernel.org/stable/c/d22e45a369afc7c28f11acfa5b5e8e478227ca5d https://git.kernel.org/stable/c/7dd34d7b7dcf9309fc6224caf4dd5b35bedddcb7 https://access.redhat.com/security/cve/CVE-2024-49888 https://bugzilla.redhat.com/show_bug.cgi?id=2320517 • CWE-190: Integer Overflow or Wraparound •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-49886 – platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug
https://notcve.org/view.php?id=CVE-2024-49886
In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] <TASK> [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? • https://git.kernel.org/stable/c/017a634f9f38ae704d9d57817555773de700219e https://git.kernel.org/stable/c/9a1aac8a96dc014bec49806a7a964bf2fdbd315f https://git.kernel.org/stable/c/1973c4d8ee0782a808303d75e3be9c12baaacd97 https://git.kernel.org/stable/c/cdd03afcb6eda3103da5a0948d3db12372f62910 https://git.kernel.org/stable/c/8176d4878ed2af5d93ddd0e971e24c412124d38b https://git.kernel.org/stable/c/cebc705b097d5c16469b141a25e840161d1c517a https://git.kernel.org/stable/c/afa7f78d9a907cfded6c98c91aae2bf7b3b56e51 https://git.kernel.org/stable/c/7d59ac07ccb58f8f604f8057db63b8efc •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49885 – mm, slub: avoid zeroing kmalloc redzone
https://notcve.org/view.php?id=CVE-2024-49885
In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with "slub_debug=FUZ init_on_free=1": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. • https://git.kernel.org/stable/c/946fa0dbf2d8923a587f7348adf16563d59f1b3d https://git.kernel.org/stable/c/7a2e823a19746d54052c625faecf0d2d6c52ee0a https://git.kernel.org/stable/c/83f0440b2f92227fcce9898118ca7fe7e0d64b1f https://git.kernel.org/stable/c/59090e479ac78ae18facd4c58eb332562a23020e •