CVSS: 4.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40978 – scsi: qedi: Fix crash while reading debugfs attribute
https://notcve.org/view.php?id=CVE-2024-40978
In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix crash while reading debugfs attribute The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly on a __user pointer, which results into the crash. To fix this issue, use a small local stack buffer for sprintf() and then call simple_read_from_buffer(), which in turns make the copy_to_user() call. BUG: unable to handle page fault for address: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Oops: 0002 [#1] PREEMPT SMP PTI Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023 RIP: 0010:memcpy_orig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? • https://git.kernel.org/stable/c/56bec63a7fc87ad50b3373a87517dc9770eef9e0 https://git.kernel.org/stable/c/21c963de2e86e88f6a8ca556bcebb8e62ab8e901 https://git.kernel.org/stable/c/144d76a676b630e321556965011b00e2de0b40a7 https://git.kernel.org/stable/c/397a8990c377ee4b61d6df768e61dff9e316d46b https://git.kernel.org/stable/c/eaddb86637669f6bad89245ee63f8fb2bfb50241 https://git.kernel.org/stable/c/fa85b016a56b9775a3fe41e5d26e666945963b46 https://git.kernel.org/stable/c/e2f433ea7d0ff77998766a088a287337fb43ad75 https://git.kernel.org/stable/c/28027ec8e32ecbadcd67623edb290dad6 • CWE-822: Untrusted Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40977 – wifi: mt76: mt7921s: fix potential hung tasks during chip recovery
https://notcve.org/view.php?id=CVE-2024-40977
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921s: fix potential hung tasks during chip recovery During chip recovery (e.g. chip reset), there is a possible situation that kernel worker reset_work is holding the lock and waiting for kernel thread stat_worker to be parked, while stat_worker is waiting for the release of the same lock. It causes a deadlock resulting in the dumping of hung tasks messages and possible rebooting of the device. This patch prevents the execution of stat_worker during the chip recovery. A vulnerability was found in the Linux kernel's mt76 driver for the mt7921s chip, where a potential deadlock could occur during chip recovery. This situation arises when the kernel worker reset_work holds a lock while waiting for the stat_worker thread, which is simultaneously waiting for the same lock to be released, which leads to hung tasks and may even result in device reboots. • https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08 https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02 https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9 https://git.kernel.org/stable/c/ecf0b2b8a37c8464186620bef37812a117ff6366 https://access.redhat.com/security/cve/CVE-2024-40977 https://bugzilla.redhat.com/show_bug.cgi?id=2297561 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40976 – drm/lima: mask irqs in timeout path before hard reset
https://notcve.org/view.php?id=CVE-2024-40976
In the Linux kernel, the following vulnerability has been resolved: drm/lima: mask irqs in timeout path before hard reset There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is done by the timeout handler. This runs into race conditions not expected by the timeout handler. In some very specific cases it currently may result in a refcount imbalance on lima_pm_idle, with a stack dump such as: [10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669628] Call trace: [10136.669634] lima_devfreq_record_idle+0xa0/0xb0 [10136.669646] lima_sched_pipe_task_done+0x5c/0xb0 [10136.669656] lima_gp_irq_handler+0xa8/0x120 [10136.669666] __handle_irq_event_percpu+0x48/0x160 [10136.669679] handle_irq_event+0x4c/0xc0 We can prevent that race condition entirely by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirely. The irqs will be enabled again at the next hard reset which is already done as a recovery by the timeout handler. • https://git.kernel.org/stable/c/03e7b2f7ae4c0ae5fb8e4e2454ba4008877f196a https://git.kernel.org/stable/c/70aa1f2dec46b6fdb5f6b9f37b6bfa4a4dee0d3a https://git.kernel.org/stable/c/9fd8ddd23793a50dbcd11c6ba51f437f1ea7d344 https://git.kernel.org/stable/c/bdbc4ca77f5eaac15de7230814253cddfed273b1 https://git.kernel.org/stable/c/58bfd311c93d66d8282bf21ebbf35cc3bb8ad9db https://git.kernel.org/stable/c/a421cc7a6a001b70415aa4f66024fa6178885a14 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-40975 – platform/x86: x86-android-tablets: Unregister devices in reverse order
https://notcve.org/view.php?id=CVE-2024-40975
In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Unregister devices in reverse order Not all subsystems support a device getting removed while there are still consumers of the device with a reference to the device. One example of this is the regulator subsystem. If a regulator gets unregistered while there are still drivers holding a reference a WARN() at drivers/regulator/core.c:5829 triggers, e.g.: WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 04/10/2015 RIP: 0010:regulator_unregister Call Trace: <TASK> regulator_unregister devres_release_group i2c_device_remove device_release_driver_internal bus_remove_device device_del device_unregister x86_android_tablet_remove On the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides a 5V boost converter output for powering USB devices connected to the micro USB port, the bq24190-charger driver exports this as a Vbus regulator. On the 830 (8") and 1050 ("10") models this regulator is controlled by a platform_device and x86_android_tablet_remove() removes platform_device-s before i2c_clients so the consumer gets removed first. But on the 1380 (13") model there is a lc824206xa micro-USB switch connected over I2C and the extcon driver for that controls the regulator. The bq24190 i2c-client *must* be registered first, because that creates the regulator with the lc824206xa listed as its consumer. If the regulator has not been registered yet the lc824206xa driver will end up getting a dummy regulator. Since in this case both the regulator provider and consumer are I2C devices, the only way to ensure that the consumer is unregistered first is to unregister the I2C devices in reverse order of in which they were created. For consistency and to avoid similar problems in the future change x86_android_tablet_remove() to unregister all device types in reverse order. • https://git.kernel.org/stable/c/f0c982853d665597d17e4995ff479fbbf79a9cf6 https://git.kernel.org/stable/c/3de0f2627ef849735f155c1818247f58404dddfe •
CVSS: 6.6EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40974 – powerpc/pseries: Enforce hcall result buffer validity and size
https://notcve.org/view.php?id=CVE-2024-40974
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Enabled for LLVM builds but not GCC for now. • https://git.kernel.org/stable/c/acf2b80c31c37acab040baa3cf5f19fbd5140b18 https://git.kernel.org/stable/c/19c166ee42cf16d8b156a6cb4544122d9a65d3ca https://git.kernel.org/stable/c/a8c988d752b3d98d5cc1e3929c519a55ef55426c https://git.kernel.org/stable/c/262e942ff5a839b9e4f3302a8987928b0c8b8a2d https://git.kernel.org/stable/c/8aa11aa001576bf3b00dcb8559564ad7a3113588 https://git.kernel.org/stable/c/3ad0034910a57aa88ed9976b1431b7b8c84e0048 https://git.kernel.org/stable/c/aa6107dcc4ce9a3451f2d729204713783b657257 https://git.kernel.org/stable/c/ff2e185cf73df480ec69675936c4ee75a • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •