CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42089 – ASoC: fsl-asoc-card: set priv->pdev before using it
https://notcve.org/view.php?id=CVE-2024-42089
In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl-asoc-card: set priv->pdev before using it priv->pdev pointer was set after being used in fsl_asoc_card_audmux_init(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv. fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations. • https://git.kernel.org/stable/c/708b4351f08c08ea93f773fb9197bdd3f3b08273 https://git.kernel.org/stable/c/ae81535ce2503aabc4adab3472f4338070cdeb6a https://git.kernel.org/stable/c/8896e18b7c366f8faf9344abfd0971435f1c723a https://git.kernel.org/stable/c/3662eb2170e59b58ad479982dc1084889ba757b9 https://git.kernel.org/stable/c/544ab46b7ece6d6bebbdee5d5659c0a0f804a99a https://git.kernel.org/stable/c/8faf91e58425c2f6ce773250dfd995f1c2d461ac https://git.kernel.org/stable/c/29bc9e7c75398b0d12fc30955f2e9b2dd29ffaed https://git.kernel.org/stable/c/7c18b4d89ff9c810b6e562408afda5ce1 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42087 – drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
https://notcve.org/view.php?id=CVE-2024-42087
In the Linux kernel, the following vulnerability has been resolved: drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue. • https://git.kernel.org/stable/c/b71348be1236398be2d04c5e145fd6eaae86a91b https://git.kernel.org/stable/c/98686ec1824728ff41d7b358131f7d0227c2ba2a https://git.kernel.org/stable/c/cae52f61fda0f5d2949dc177f984c9e187d4c6a0 https://git.kernel.org/stable/c/489f38de3375ab84b3d269d0a1d64d6ee95d7044 https://git.kernel.org/stable/c/5f41401219fbe7663b3cf65ebd4ed95ebbb8ffb9 https://git.kernel.org/stable/c/1618f7a875ffd916596392fd29880c0429b8af60 https://git.kernel.org/stable/c/e646402bf82145349fcf5dcbe395afaf02a8ce47 https://git.kernel.org/stable/c/ee7860cd8b5763017f8dc785c2851fecb •
CVSS: 6.3EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42084 – ftruncate: pass a signed offset
https://notcve.org/view.php?id=CVE-2024-42084
In the Linux kernel, the following vulnerability has been resolved: ftruncate: pass a signed offset The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB. Changing the type of the compat syscall to the signed compat_off_t changes the behavior so it instead returns -EINVAL. The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake. • https://git.kernel.org/stable/c/3f6d078d4accfff8b114f968259a060bfdc7c682 https://git.kernel.org/stable/c/c329760749b5419769e57cb2be80955d2805f9c9 https://git.kernel.org/stable/c/f531d4bc6c5588d713359e42ed65e46816d841d8 https://git.kernel.org/stable/c/84bf6b64a1a0dfc6de7e1b1c776d58d608e7865a https://git.kernel.org/stable/c/dbb226d81cd02cee140139c2369791e6f61f2007 https://git.kernel.org/stable/c/5ae6af68410bdad6181ec82104bb9985a7a6a0fa https://git.kernel.org/stable/c/836359247b0403e0634bfbc83e5bb8063fad287a https://git.kernel.org/stable/c/930a4c369f74da26816eaaa71b5888d29 • CWE-96: Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection') •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42082 – xdp: Remove WARN() from __xdp_reg_mem_model()
https://notcve.org/view.php?id=CVE-2024-42082
In the Linux kernel, the following vulnerability has been resolved: xdp: Remove WARN() from __xdp_reg_mem_model() syzkaller reports a warning in __xdp_reg_mem_model(). The warning occurs only if __mem_id_init_hash_table() returns an error. It returns the error in two cases: 1. memory allocation fails; 2. rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly. The second case cannot happen since there is a static const rhashtable_params struct with valid fields. So, warning is only triggered when there is a problem with memory allocation. Thus, there is no sense in using WARN() to handle this error and it can be safely removed. WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Found by Linux Verification Center (linuxtesting.org) with syzkaller. • https://git.kernel.org/stable/c/8d5d88527587516bd58ff0f3810f07c38e65e2be https://git.kernel.org/stable/c/1095b8efbb13a6a5fa583ed373ee1ccab29da2d0 https://git.kernel.org/stable/c/1d3e3b3aa2cbe9bc7db9a7f8673a9fa6d2990d54 https://git.kernel.org/stable/c/4e0c539ee265d5c6e7fa7d229cd4aa7bc01816e2 https://git.kernel.org/stable/c/14e51ea78b4ccacb7acb1346b9241bb790a2054c https://git.kernel.org/stable/c/f92298b0467fd77edc4c1a2c3e48833e69840ec4 https://git.kernel.org/stable/c/7e9f79428372c6eab92271390851be34ab26bfb4 https://access.redhat.com/security/cve/CVE-2024-42082 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42081 – drm/xe/xe_devcoredump: Check NULL before assignments
https://notcve.org/view.php?id=CVE-2024-42081
In the Linux kernel, the following vulnerability has been resolved: drm/xe/xe_devcoredump: Check NULL before assignments Assign 'xe_devcoredump_snapshot *' and 'xe_device *' only if 'coredump' is not NULL. v2 - Fix commit messages. v3 - Define variables before code.(Ashutosh/Jose) v4 - Drop return check for coredump_to_xe. (Jose/Rodrigo) v5 - Modify misleading commit message. (Matt) • https://git.kernel.org/stable/c/76ec0e33707282d5321555698d902f4e067aff37 https://git.kernel.org/stable/c/b15e65349553b1689d15fbdebea874ca5ae2274a •