CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50020 – ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()
https://notcve.org/view.php?id=CVE-2024-50020
In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. • https://git.kernel.org/stable/c/4d38cb44bd321c81da3457cfbc38501ed8cb6714 https://git.kernel.org/stable/c/3345e7cf0cf82027bff3b7878bd79214688e61da https://git.kernel.org/stable/c/416dbb815ca69684de148328990ba0ec53e6dbc1 https://git.kernel.org/stable/c/d517cf89874c6039e6294b18d66f40988e62502a •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50019 – kthread: unpark only parked kthread
https://notcve.org/view.php?id=CVE-2024-50019
In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 <TASK> kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Fix this with skipping unecessary unparking while stopping a kthread. • https://git.kernel.org/stable/c/5c25b5ff89f004c30b04759dc34ace8585a4085f https://git.kernel.org/stable/c/40a6e660d2a3a7a5cb99f0b8ff4fb41bad039f68 https://git.kernel.org/stable/c/8608196a155cb6cfae04d96b10a2652d0327e33f https://git.kernel.org/stable/c/19a5029981c87c2ad0845e713837faa88f5d8e2b https://git.kernel.org/stable/c/cda5423c1a1c906062ef235c940f249b97d9d135 https://git.kernel.org/stable/c/214e01ad4ed7158cab66498810094fac5d09b218 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50017 – x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
https://notcve.org/view.php?id=CVE-2024-50017
In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. • https://git.kernel.org/stable/c/d80a99892f7a992d103138fa4636b2c33abd6740 https://git.kernel.org/stable/c/a23823098ab2c277c14fc110b97d8d5c83597195 https://git.kernel.org/stable/c/cc31744a294584a36bf764a0ffa3255a8e69f036 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50016 – drm/amd/display: Avoid overflow assignment in link_dp_cts
https://notcve.org/view.php?id=CVE-2024-50016
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity. • https://git.kernel.org/stable/c/a1495acc6234fa79b775599d3f49009afd53299f https://git.kernel.org/stable/c/26ced9d86240868f5b41708ceee02e6ec2924498 https://git.kernel.org/stable/c/adeed800bc30ef718478b28c08f79231e5980e3d https://git.kernel.org/stable/c/a15268787b79fd183dd526cc16bec9af4f4e49a1 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50015 – ext4: dax: fix overflowing extents beyond inode size when partially writing
https://notcve.org/view.php?id=CVE-2024-50015
In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected. • https://git.kernel.org/stable/c/776722e85d3b0936253ecc3d14db4fba37f191ba https://git.kernel.org/stable/c/f8a7c342326f6ad1dfdb30a18dd013c70f5e9669 https://git.kernel.org/stable/c/8c30a9a8610c314554997f86370140746aa35661 https://git.kernel.org/stable/c/abfaa876b948baaea4d14f21a1963789845c8b4c https://git.kernel.org/stable/c/5efccdee4a7d507a483f20f880b809cc4eaef14d https://git.kernel.org/stable/c/a9f331f51515bdb3ebc8d0963131af367ef468f6 https://git.kernel.org/stable/c/ec0dd451e236c46e4858d53e9e82bae7797a7af5 https://git.kernel.org/stable/c/dda898d7ffe85931f9cca6d702a51f337 •