CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50028 – thermal: core: Reference count the zone in thermal_zone_get_by_id()
https://notcve.org/view.php?id=CVE-2024-50028
In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure. • https://git.kernel.org/stable/c/1ce50e7d408ef2bdc8ca021363fd46d1b8bfad00 https://git.kernel.org/stable/c/c95538b286efc6109c987e97a051bc7844ede802 https://git.kernel.org/stable/c/a42a5839f400e929c489bb1b58f54596c4535167 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50024 – net: Fix an unsafe loop on the list
https://notcve.org/view.php?id=CVE-2024-50024
In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list. • https://git.kernel.org/stable/c/b8273570f802a7658827dcb077b0b517ba75a289 https://git.kernel.org/stable/c/464801a0f6ccb52b21faa33bac6014fd74cc5e10 https://git.kernel.org/stable/c/8e0766fcf37ad8eed289dd3853628dd9b01b58b0 https://git.kernel.org/stable/c/68ad5da6ca630a276f0a5c924179e57724d00013 https://git.kernel.org/stable/c/1cdec792b2450105b1314c5123a9a0452cb2c2f0 https://git.kernel.org/stable/c/5f03a7f601f33cda1f710611625235dc86fd8a9e https://git.kernel.org/stable/c/3be342e0332a7c83eb26fbb22bf156fdca467a5d https://git.kernel.org/stable/c/49f9b726bf2bf3dd2caf0d27cadf4bc1c •
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-50018 – net: napi: Prevent overflow of napi_defer_hard_irqs
https://notcve.org/view.php?id=CVE-2024-50018
In the Linux kernel, the following vulnerability has been resolved: net: napi: Prevent overflow of napi_defer_hard_irqs In commit 6f8b12d661d0 ("net: napi: add hard irqs deferral feature") napi_defer_irqs was added to net_device and napi_defer_irqs_count was added to napi_struct, both as type int. This value never goes below zero, so there is not reason for it to be a signed int. Change the type for both from int to u32, and add an overflow check to sysfs to limit the value to S32_MAX. The limit of S32_MAX was chosen because the practical limit before this patch was S32_MAX (anything larger was an overflow) and thus there are no behavioral changes introduced. If the extra bit is needed in the future, the limit can be raised. Before this patch: $ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs' $ cat /sys/class/net/eth4/napi_defer_hard_irqs -2147483647 After this patch: $ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs' bash: line 0: echo: write error: Numerical result out of range Similarly, /sys/class/net/XXXXX/tx_queue_len is defined as unsigned: include/linux/netdevice.h: unsigned int tx_queue_len; And has an overflow check: dev_change_tx_queue_len(..., unsigned long new_len): if (new_len != (unsigned int)new_len) return -ERANGE; • https://git.kernel.org/stable/c/d694ad8b7e5004df86ecd415cb2320d543723672 https://git.kernel.org/stable/c/5e753b743d3b38a3e10be666c32c5434423d0093 https://git.kernel.org/stable/c/08062af0a52107a243f7608fd972edb54ca5b7f8 •
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 •