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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40973 – media: mtk-vcodec: potential null pointer deference in SCP
https://notcve.org/view.php?id=CVE-2024-40973
In the Linux kernel, the following vulnerability has been resolved: media: mtk-vcodec: potential null pointer deference in SCP The return value of devm_kzalloc() needs to be checked to avoid NULL pointer deference. This is similar to CVE-2022-3113. • https://git.kernel.org/stable/c/f066882293b5ad359e44c4ed24ab1811ffb0b354 https://git.kernel.org/stable/c/3a693c7e243b932faee5c1fb728efa73f0abc39b https://git.kernel.org/stable/c/53dbe08504442dc7ba4865c09b3bbf5fe849681b •
CVSS: 4.1EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40972 – ext4: do not create EA inode under buffer lock
https://notcve.org/view.php?id=CVE-2024-40972
In the Linux kernel, the following vulnerability has been resolved: ext4: do not create EA inode under buffer lock ext4_xattr_set_entry() creates new EA inodes while holding buffer lock on the external xattr block. This is problematic as it nests all the allocation locking (which acquires locks on other buffers) under the buffer lock. This can even deadlock when the filesystem is corrupted and e.g. quota file is setup to contain xattr block as data block. Move the allocation of EA inode out of ext4_xattr_set_entry() into the callers. • https://git.kernel.org/stable/c/0752e7fb549d90c33b4d4186f11cfd25a556d1dd https://git.kernel.org/stable/c/737fb7853acd5bc8984f6f42e4bfba3334be8ae1 https://git.kernel.org/stable/c/111103907234bffd0a34fba070ad9367de058752 https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b https://access.redhat.com/security/cve/CVE-2024-40972 https://bugzilla.redhat.com/show_bug.cgi?id=2297556 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40971 – f2fs: remove clear SB_INLINECRYPT flag in default_options
https://notcve.org/view.php?id=CVE-2024-40971
In the Linux kernel, the following vulnerability has been resolved: f2fs: remove clear SB_INLINECRYPT flag in default_options In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again • https://git.kernel.org/stable/c/38a82c8d00638bb642bef787eb1d5e0e4d3b7d71 https://git.kernel.org/stable/c/724429db09e21ee153fef35e34342279d33df6ae https://git.kernel.org/stable/c/a9cea0489c562c97cd56bb345e78939f9909e7f4 https://git.kernel.org/stable/c/eddeb8d941d5be11a9da5637dbe81ac37e8449a2 https://git.kernel.org/stable/c/ae39c8ec4250d2a35ddaab1c40faacfec306ff66 https://git.kernel.org/stable/c/ac5eecf481c29942eb9a862e758c0c8b68090c33 •