CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49891 – scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths
https://notcve.org/view.php?id=CVE-2024-49891
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler. • https://git.kernel.org/stable/c/99a801e2fca39a6f31e543fc3383058a8955896f https://git.kernel.org/stable/c/fd665c8dbdb19548965b0ae80c490de00e906366 https://git.kernel.org/stable/c/2be1d4f11944cd6283cb97268b3e17c4424945ca •
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: -EPSS: 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/4902a6a0dc593c82055fc8c9ada371bafe26c9cc https://git.kernel.org/stable/c/d22e45a369afc7c28f11acfa5b5e8e478227ca5d https://git.kernel.org/stable/c/7dd34d7b7dcf9309fc6224caf4dd5b35bedddcb7 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49887 – f2fs: fix to don't panic system for no free segment fault injection
https://notcve.org/view.php?id=CVE-2024-49887
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it. • https://git.kernel.org/stable/c/8b10d3653735e117bc1954ade80d75ad7b46b801 https://git.kernel.org/stable/c/9f6e7a0512a57387d36f5e9e9635d6668cac13dd https://git.kernel.org/stable/c/645ec43760e86d3079fee2e8b51fde7060a540d0 https://git.kernel.org/stable/c/65a6ce4726c27b45600303f06496fef46d00b57f •