ISHACK AI BOT

Oracle Linux: CVE-2024-56627: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read An offset from client could be a negative value, It could lead to an out-of-bounds read from the stream_buf. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56627 CVE - 2024-56627 ELSA-2025-20095

Oracle Linux: CVE-2024-56572: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal() The buffer in the loop should be released under the exception path, otherwise there may be a memory leak here. To mitigate this, free the buffer when allegro_alloc_buffer fails. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56572 CVE - 2024-56572 ELSA-2025-20095 ELSA-2025-20100

Debian: CVE-2024-53215: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 02/06/2025 Description In the Linux kernel, the following vulnerability has been resolved: svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init() There's issue as follows: RPC: Registered rdma transport module. RPC: Registered rdma backchannel transport module. RPC: Unregistered rdma transport module. RPC: Unregistered rdma backchannel transport module. BUG: unable to handle page fault for address: fffffbfff80c609a PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0 Call Trace: <TASK> __die+0x1f/0x70 page_fault_oops+0x2cd/0x860 spurious_kernel_fault+0x36/0x450 do_kern_addr_fault+0xca/0x100 exc_page_fault+0x128/0x150 asm_exc_page_fault+0x26/0x30 percpu_counter_destroy_many+0xf7/0x2a0 mmdrop+0x209/0x350 finish_task_switch.isra.0+0x481/0x840 schedule_tail+0xe/0xd0 ret_from_fork+0x23/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not destroy the percpu counters which init in svc_rdma_proc_init(). If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the 'percpu_counters' list. The above issue may occur once the module is removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory leakage occurs. To solve above issue just destroy all percpu counters when register_sysctl() return NULL. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53215 CVE - 2024-53215

Debian: CVE-2024-56587: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 02/03/2025 Description In the Linux kernel, the following vulnerability has been resolved: leds: class: Protect brightness_show() with led_cdev->led_access mutex There is NULL pointer issue observed if from Process A where hid device being added which results in adding a led_cdev addition and later a another call to access of led_cdev attribute from Process B can result in NULL pointer issue. Use mutex led_cdev->led_access to protect access to led->cdev and its attribute inside brightness_show() and max_brightness_show() and also update the comment for mutex that it should be used to protect the led class device fields. Process A Process B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74 [ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 3313.874301][ T4013] Mem abort info: [ 3313.874303][ T4013] ESR = 0x0000000096000006 [ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits [ 3313.874307][ T4013] SET = 0, FnV = 0 [ 3313.874309][ T4013] EA = 0, S1PTW = 0 [ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault [ 3313.874313][ T4013] Data abort info: [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000 .. [ 3313.874332][ T4013] Dumping ftrace buffer: [ 3313.874334][ T4013](ftrace buffer empty) .. .. [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74 [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60 [ 3313.874656][ T4013] sp : ffffffc0b910bbd0 .. .. [ 3313.874685][ T4013] Call trace: [ 3313.874687][ T4013]dualshock4_led_get_brightness+0xc/0x74 [ 3313.874690][ T4013]brightness_show+0x20/0x4c [ 3313.874692][ T4013]dev_attr_show+0x38/0x74 [ 3313.874696][ T4013]sysfs_kf_seq_show+0xb4/0x130 [ 3313.874700][ T4013]kernfs_seq_show+0x44/0x54 [ 3313.874703][ T4013]seq_read_iter+0x158/0x4ec [ 3313.874705][ T4013]kernfs_fop_read_iter+0x68/0x1b4 [ 3313.874708][ T4013]vfs_read+0x1e0/0x2c8 [ 3313.874711][ T4013]ksys_read+0x78/0xe8 [ 3313.874714][ T4013]__arm64_sys_read+0x1c/0x2c [ 3313.874718][ T4013]invoke_syscall+0x58/0x114 [ 3313.874721][ T4013]el0_svc_common+0x80/0xe0 [ 3313.874724][ T4013]do_el0_svc+0x1c/0x28 [ 3313.874727][ T4013]el0_svc+0x38/0x68 [ 3313.874730][ T4013]el0t_64_sync_handler+0x68/0xbc [ 3313.874732][ T4013]el0t_64_sync+0x1a8/0x1ac Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56587 CVE - 2024-56587

Debian: CVE-2024-56599: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 02/11/2025 Added 02/10/2025 Modified 02/10/2025 Description In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189 Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56599 CVE - 2024-56599 DSA-5860-1

Oracle Linux: CVE-2024-53214: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Properly hide first-in-list PCIe extended capability There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user. Hiding a capability is done by virtualizing and modifying the &apos;Next Capability Offset&apos; field of the previous capability so it points to the capability after the one that should be hidden. The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list. However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device-&gt;pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array. Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array. Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before). [1] WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: &lt;TASK&gt; ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-53214 CVE - 2024-53214 ELSA-2025-20095 ELSA-2025-20100

Oracle Linux: CVE-2024-53217: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent NULL dereference in nfsd4_process_cb_update() @ses is initialized to NULL. If __nfsd4_find_backchannel() finds no available backchannel session, setup_callback_client() will try to dereference @ses and segfault. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-53217 CVE - 2024-53217 ELSA-2025-20095 ELSA-2025-20100

Oracle Linux: CVE-2024-53239: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Release resources at card release The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort().But at this moment, the card object might be still in use (as we&apos;re calling snd_card_free_when_closed()). For avoid potential UAFs, move the release of resources to the card&apos;s private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-53239 CVE - 2024-53239 ELSA-2025-20095 ELSA-2025-20100

Debian: CVE-2024-56539: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan() Replace one-element array with a flexible-array member in `struct mwifiex_ie_types_wildcard_ssid_params` to fix the following warning on a MT8173 Chromebook (mt8173-elm-hana): [356.775250] ------------[ cut here ]------------ [356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex] The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like: ssid_len = user_scan_in->ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv->ssid, user_scan_in->ssid_list[i].ssid, ssid_len); There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56539 CVE - 2024-56539

Oracle Linux: CVE-2024-56570: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: ovl: Filter invalid inodes with missing lookup function Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56570 CVE - 2024-56570 ELSA-2025-20095 ELSA-2025-20100

Oracle Linux: CVE-2024-56571: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Require entities to have a non-zero unique ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` So, deny allocating an entity with ID 0 or an ID that belongs to a unit that is already added to the list of entities. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device &lt;unnamed&gt; (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 &lt;0f&gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS:0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480]&lt;TASK&gt; [ 21.051611]? __warn+0xc4/0x210 [ 21.051861]? media_create_pad_link+0x2c4/0x2e0 [ 21.052252]? report_bug+0x11b/0x1a0 [ 21.052540]? trace_hardirqs_on+0x31/0x40 [ 21.052901]? handle_bug+0x3d/0x70 [ 21.053197]? exc_invalid_op+0x1a/0x50 [ 21.053511]? asm_exc_invalid_op+0x1a/0x20 [ 21.053924]? media_create_pad_link+0x91/0x2e0 [ 21.054364]? media_create_pad_link+0x2c4/0x2e0 [ 21.054834]? media_create_pad_link+0x91/0x2e0 [ 21.055131]? _raw_spin_unlock+0x1e/0x40 [ 21.055441]? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837]uvc_mc_register_entities+0x358/0x400 [ 21.056144]uvc_register_chains+0x1fd/0x290 [ 21.056413]uvc_probe+0x380e/0x3dc0 [ 21.056676]? __lock_acquire+0x5aa/0x26e0 [ 21.056946]? find_held_lock+0x33/0xa0 [ 21.057196]? kernfs_activate+0x70/0x80 [ 21.057533]? usb_match_dy ---truncated--- Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56571 CVE - 2024-56571 ELSA-2025-20095

VMware Photon OS: CVE-2024-56615 Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: fix OOB devmap writes when deleting elements Jordy reported issue against XSKMAP which also applies to DEVMAP - the index used for accessing map entry, due to being a signed integer, causes the OOB writes. Fix is simple as changing the type from int to u32, however, when compared to XSKMAP case, one more thing needs to be addressed. When map is released from system via dev_map_free(), we iterate through all of the entries and an iterator variable is also an int, which implies OOB accesses. Again, change it to be u32. Example splat below: [160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000 [160.731662] #PF: supervisor read access in kernel mode [160.736876] #PF: error_code(0x0000) - not-present page [160.742095] PGD 0 P4D 0 [160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487 [160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [160.767642] Workqueue: events_unbound bpf_map_free_deferred [160.773308] RIP: 0010:dev_map_free+0x77/0x170 [160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024 [160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000 [160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122 [160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [160.838310] FS:0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [160.846528] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [160.874092] PKRU: 55555554 [160.876847] Call Trace: [160.879338]<TASK> [160.881477]? __die+0x20/0x60 [160.884586]? page_fault_oops+0x15a/0x450 [160.888746]? search_extable+0x22/0x30 [160.892647]? search_bpf_extables+0x5f/0x80 [160.896988]? exc_page_fault+0xa9/0x140 [160.900973]? asm_exc_page_fault+0x22/0x30 [160.905232]? dev_map_free+0x77/0x170 [160.909043]? dev_map_free+0x58/0x170 [160.912857]bpf_map_free_deferred+0x51/0x90 [160.917196]process_one_work+0x142/0x370 [160.921272]worker_thread+0x29e/0x3b0 [160.925082]? rescuer_thread+0x4b0/0x4b0 [160.929157]kthread+0xd4/0x110 [160.932355]? kthread_park+0x80/0x80 [160.936079]ret_from_fork+0x2d/0x50 [160.943396]? kthread_park+0x80/0x80 [160.950803]ret_from_fork_asm+0x11/0x20 [160.958482]</TASK> Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-56615 CVE - 2024-56615

Debian: CVE-2024-56594: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: set the right AMDGPU sg segment limitation The driver needs to set the correct max_segment_size; otherwise debug_dma_map_sg() will complain about the over-mapping of the AMDGPU sg length as following: WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370 [364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd [364.049532]ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE6.10.0-custom #492 [364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370 [364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05 [364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286 [364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027 [364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680 [364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930 [364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000 [364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800 [364.049599] FS:00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000 [364.049601] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0 [364.049605] Call Trace: [364.049607]<TASK> [364.049609]? show_regs+0x6d/0x80 [364.049614]? __warn+0x8c/0x140 [364.049618]? debug_dma_map_sg+0x2dc/0x370 [364.049621]? report_bug+0x193/0x1a0 [364.049627]? handle_bug+0x46/0x80 [364.049631]? exc_invalid_op+0x1d/0x80 [364.049635]? asm_exc_invalid_op+0x1f/0x30 [364.049642]? debug_dma_map_sg+0x2dc/0x370 [364.049647]__dma_map_sg_attrs+0x90/0xe0 [364.049651]dma_map_sgtable+0x25/0x40 [364.049654]amdgpu_bo_move+0x59a/0x850 [amdgpu] [364.049935]? srso_return_thunk+0x5/0x5f [364.049939]? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu] [364.050095]ttm_bo_handle_move_mem+0xc3/0x180 [ttm] [364.050103]ttm_bo_validate+0xc1/0x160 [ttm] [364.050108]? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu] [364.050263]amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu] [364.050473]kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu] [364.050680]kfd_ioctl+0x3c2/0x530 [amdgpu] [364.050866]? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu] [364.05105 ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56594 CVE - 2024-56594

Oracle Linux: CVE-2024-53215: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init() There&apos;s issue as follows: RPC: Registered rdma transport module. RPC: Registered rdma backchannel transport module. RPC: Unregistered rdma transport module. RPC: Unregistered rdma backchannel transport module. BUG: unable to handle page fault for address: fffffbfff80c609a PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0 Call Trace: &lt;TASK&gt; __die+0x1f/0x70 page_fault_oops+0x2cd/0x860 spurious_kernel_fault+0x36/0x450 do_kern_addr_fault+0xca/0x100 exc_page_fault+0x128/0x150 asm_exc_page_fault+0x26/0x30 percpu_counter_destroy_many+0xf7/0x2a0 mmdrop+0x209/0x350 finish_task_switch.isra.0+0x481/0x840 schedule_tail+0xe/0xd0 ret_from_fork+0x23/0x80 ret_from_fork_asm+0x1a/0x30 &lt;/TASK&gt; If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not destroy the percpu counters which init in svc_rdma_proc_init(). If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the &apos;percpu_counters&apos; list. The above issue may occur once the module is removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory leakage occurs. To solve above issue just destroy all percpu counters when register_sysctl() return NULL. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-53215 CVE - 2024-53215 ELSA-2025-20095

VMware Photon OS: CVE-2024-56664 Severity 6 CVSS (AV:L/AC:H/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/30/2025 Added 01/29/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix race between element replace and close() Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element: // set map[0] = s0 map_update_elem(map, 0, s0) // drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk// s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk)// unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk) Then close(map) enqueues bpf_map_free_deferred, which finally calls sock_map_free(). This results in some refcount_t warnings along with a KASAN splat [1]. Fix __sock_map_delete(), do not allow sock_map_unref() on elements that may have been replaced. [1]: BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330 Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred Call Trace: <TASK> dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 The bu ---truncated--- Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-56664 CVE - 2024-56664

Debian: CVE-2024-56615: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: fix OOB devmap writes when deleting elements Jordy reported issue against XSKMAP which also applies to DEVMAP - the index used for accessing map entry, due to being a signed integer, causes the OOB writes. Fix is simple as changing the type from int to u32, however, when compared to XSKMAP case, one more thing needs to be addressed. When map is released from system via dev_map_free(), we iterate through all of the entries and an iterator variable is also an int, which implies OOB accesses. Again, change it to be u32. Example splat below: [160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000 [160.731662] #PF: supervisor read access in kernel mode [160.736876] #PF: error_code(0x0000) - not-present page [160.742095] PGD 0 P4D 0 [160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487 [160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [160.767642] Workqueue: events_unbound bpf_map_free_deferred [160.773308] RIP: 0010:dev_map_free+0x77/0x170 [160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024 [160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000 [160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122 [160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [160.838310] FS:0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [160.846528] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [160.874092] PKRU: 55555554 [160.876847] Call Trace: [160.879338]<TASK> [160.881477]? __die+0x20/0x60 [160.884586]? page_fault_oops+0x15a/0x450 [160.888746]? search_extable+0x22/0x30 [160.892647]? search_bpf_extables+0x5f/0x80 [160.896988]? exc_page_fault+0xa9/0x140 [160.900973]? asm_exc_page_fault+0x22/0x30 [160.905232]? dev_map_free+0x77/0x170 [160.909043]? dev_map_free+0x58/0x170 [160.912857]bpf_map_free_deferred+0x51/0x90 [160.917196]process_one_work+0x142/0x370 [160.921272]worker_thread+0x29e/0x3b0 [160.925082]? rescuer_thread+0x4b0/0x4b0 [160.929157]kthread+0xd4/0x110 [160.932355]? kthread_park+0x80/0x80 [160.936079]ret_from_fork+0x2d/0x50 [160.943396]? kthread_park+0x80/0x80 [160.950803]ret_from_fork_asm+0x11/0x20 [160.958482]</TASK> Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56615 CVE - 2024-56615

Oracle Linux: CVE-2024-56532: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: ALSA: us122l: Use snd_card_free_when_closed() at disconnection The USB disconnect callback is supposed to be short and not too-long waiting.OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long.It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed().This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. The loop of us122l-&gt;mmap_count check is dropped as well.The check is useless for the asynchronous operation with *_when_closed(). Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56532 CVE - 2024-56532 ELSA-2025-20095 ELSA-2025-20100

Debian: CVE-2024-53170: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 02/11/2025 Added 02/10/2025 Modified 02/10/2025 Description In the Linux kernel, the following vulnerability has been resolved: block: fix uaf for flush rq while iterating tags blk_mq_clear_flush_rq_mapping() is not called during scsi probe, by checking blk_queue_init_done(). However, QUEUE_FLAG_INIT_DONE is cleared in del_gendisk by commit aec89dc5d421 ("block: keep q_usage_counter in atomic mode after del_gendisk"), hence for disk like scsi, following blk_mq_destroy_queue() will not clear flush rq from tags->rqs[] as well, cause following uaf that is found by our syzkaller for v6.6: ================================================================== BUG: KASAN: slab-use-after-free in blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261 Read of size 4 at addr ffff88811c969c20 by task kworker/1:2H/224909 CPU: 1 PID: 224909 Comm: kworker/1:2H Not tainted 6.6.0-ga836a5060850 #32 Workqueue: kblockd blk_mq_timeout_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364 print_report+0x3e/0x70 mm/kasan/report.c:475 kasan_report+0xb8/0xf0 mm/kasan/report.c:588 blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261 bt_iter block/blk-mq-tag.c:288 [inline] __sbitmap_for_each_set include/linux/sbitmap.h:295 [inline] sbitmap_for_each_set include/linux/sbitmap.h:316 [inline] bt_for_each+0x455/0x790 block/blk-mq-tag.c:325 blk_mq_queue_tag_busy_iter+0x320/0x740 block/blk-mq-tag.c:534 blk_mq_timeout_work+0x1a3/0x7b0 block/blk-mq.c:1673 process_one_work+0x7c4/0x1450 kernel/workqueue.c:2631 process_scheduled_works kernel/workqueue.c:2704 [inline] worker_thread+0x804/0xe40 kernel/workqueue.c:2785 kthread+0x346/0x450 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:293 Allocated by task 942: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc mm/kasan/common.c:383 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:380 kasan_kmalloc include/linux/kasan.h:198 [inline] __do_kmalloc_node mm/slab_common.c:1007 [inline] __kmalloc_node+0x69/0x170 mm/slab_common.c:1014 kmalloc_node include/linux/slab.h:620 [inline] kzalloc_node include/linux/slab.h:732 [inline] blk_alloc_flush_queue+0x144/0x2f0 block/blk-flush.c:499 blk_mq_alloc_hctx+0x601/0x940 block/blk-mq.c:3788 blk_mq_alloc_and_init_hctx+0x27f/0x330 block/blk-mq.c:4261 blk_mq_realloc_hw_ctxs+0x488/0x5e0 block/blk-mq.c:4294 blk_mq_init_allocated_queue+0x188/0x860 block/blk-mq.c:4350 blk_mq_init_queue_data block/blk-mq.c:4166 [inline] blk_mq_init_queue+0x8d/0x100 block/blk-mq.c:4176 scsi_alloc_sdev+0x843/0xd50 drivers/scsi/scsi_scan.c:335 scsi_probe_and_add_lun+0x77c/0xde0 drivers/scsi/scsi_scan.c:1189 __scsi_scan_target+0x1fc/0x5a0 drivers/scsi/scsi_scan.c:1727 scsi_scan_channel drivers/scsi/scsi_scan.c:1815 [inline] scsi_scan_channel+0x14b/0x1e0 drivers/scsi/scsi_scan.c:1791 scsi_scan_host_selected+0x2fe/0x400 drivers/scsi/scsi_scan.c:1844 scsi_scan+0x3a0/0x3f0 drivers/scsi/scsi_sysfs.c:151 store_scan+0x2a/0x60 drivers/scsi/scsi_sysfs.c:191 dev_attr_store+0x5c/0x90 drivers/base/core.c:2388 sysfs_kf_write+0x11c/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x3fc/0x610 fs/kernfs/file.c:338 call_write_iter include/linux/fs.h:2083 [inline] new_sync_write+0x1b4/0x2d0 fs/read_write.c:493 vfs_write+0x76c/0xb00 fs/read_write.c:586 ksys_write+0x127/0x250 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Freed by task 244687: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 [inline] __kasan_slab_free+0x12a/0x1b0 mm/kasan/common.c:244 kasan_slab_free include/linux/kasan.h:164 [in ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53170 CVE - 2024-53170 DSA-5860-1

Debian: CVE-2024-56548: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: hfsplus: don't query the device logical block size multiple times Devices block sizes may change. One of these cases is a loop device by using ioctl LOOP_SET_BLOCK_SIZE. While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the latter function reads a different io_size. Using a new min_io_size initally set to sb_min_blocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not initialized. Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096. The produced KASAN report before the fix looks like this: [419.944641] ================================================================== [419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a [419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [419.947612] [419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [419.950035] Call Trace: [419.950384]<TASK> [419.950676]dump_stack_lvl+0x57/0x78 [419.951212]? hfsplus_read_wrapper+0x659/0xa0a [419.951830]print_report+0x14c/0x49e [419.952361]? __virt_addr_valid+0x267/0x278 [419.952979]? kmem_cache_debug_flags+0xc/0x1d [419.953561]? hfsplus_read_wrapper+0x659/0xa0a [419.954231]kasan_report+0x89/0xb0 [419.954748]? hfsplus_read_wrapper+0x659/0xa0a [419.955367]hfsplus_read_wrapper+0x659/0xa0a [419.955948]? __pfx_hfsplus_read_wrapper+0x10/0x10 [419.956618]? do_raw_spin_unlock+0x59/0x1a9 [419.957214]? _raw_spin_unlock+0x1a/0x2e [419.957772]hfsplus_fill_super+0x348/0x1590 [419.958355]? hlock_class+0x4c/0x109 [419.958867]? __pfx_hfsplus_fill_super+0x10/0x10 [419.959499]? __pfx_string+0x10/0x10 [419.960006]? lock_acquire+0x3e2/0x454 [419.960532]? bdev_name.constprop.0+0xce/0x243 [419.961129]? __pfx_bdev_name.constprop.0+0x10/0x10 [419.961799]? pointer+0x3f0/0x62f [419.962277]? __pfx_pointer+0x10/0x10 [419.962761]? vsnprintf+0x6c4/0xfba [419.963178]? __pfx_vsnprintf+0x10/0x10 [419.963621]? setup_bdev_super+0x376/0x3b3 [419.964029]? snprintf+0x9d/0xd2 [419.964344]? __pfx_snprintf+0x10/0x10 [419.964675]? lock_acquired+0x45c/0x5e9 [419.965016]? set_blocksize+0x139/0x1c1 [419.965381]? sb_set_blocksize+0x6d/0xae [419.965742]? __pfx_hfsplus_fill_super+0x10/0x10 [419.966179]mount_bdev+0x12f/0x1bf [419.966512]? __pfx_mount_bdev+0x10/0x10 [419.966886]? vfs_parse_fs_string+0xce/0x111 [419.967293]? __pfx_vfs_parse_fs_string+0x10/0x10 [419.967702]? __pfx_hfsplus_mount+0x10/0x10 [419.968073]legacy_get_tree+0x104/0x178 [419.968414]vfs_get_tree+0x86/0x296 [419.968751]path_mount+0xba3/0xd0b [419.969157]? __pfx_path_mount+0x10/0x10 [419.969594]? kmem_cache_free+0x1e2/0x260 [419.970311]do_mount+0x99/0xe0 [419.970630]? __pfx_do_mount+0x10/0x10 [419.971008]__do_sys_mount+0x199/0x1c9 [419.971397]do_syscall_64+0xd0/0x135 [419.971761]entry_SYSCALL_64_after_hwframe+0x76/0x7e [419.972233] RIP: 0033:0x7c3cb812972e [419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56548 CVE - 2024-56548

Oracle Linux: CVE-2024-56568: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu: Defer probe of clients after smmu device bound Null pointer dereference occurs due to a race between smmu driver probe and client driver probe, when of_dma_configure() for client is called after the iommu_device_register() for smmu driver probe has executed but before the driver_bound() for smmu driver has been called. Following is how the race occurs: T1:Smmu device probeT2: Client device probe really_probe() arm_smmu_device_probe() iommu_device_register() really_probe() platform_dma_configure() of_dma_configure() of_dma_configure_id() of_iommu_configure() iommu_probe_device() iommu_init_device() arm_smmu_probe_device() arm_smmu_get_by_fwnode() driver_find_device_by_fwnode() driver_find_device() next_device() klist_next() /* null ptr assigned to smmu */ /* null ptr dereference while smmu-&gt;streamid_mask */ driver_bound() klist_add_tail() When this null smmu pointer is dereferenced later in arm_smmu_probe_device, the device crashes. Fix this by deferring the probe of the client device until the smmu device has bound to the arm smmu driver. [will: Add comment] Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56568 CVE - 2024-56568 ELSA-2025-20095

Debian: CVE-2024-53206: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: tcp: Fix use-after-free of nreq in reqsk_timer_handler(). The cited commit replaced inet_csk_reqsk_queue_drop_and_put() with __inet_csk_reqsk_queue_drop() and reqsk_put() in reqsk_timer_handler(). Then, oreq should be passed to reqsk_put() instead of req; otherwise use-after-free of nreq could happen when reqsk is migrated but the retry attempt failed (e.g. due to timeout). Let's pass oreq to reqsk_put(). Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53206 CVE - 2024-53206

Oracle Linux: CVE-2024-56569: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix regression with module command in stack_trace_filter When executing the following command: # echo &quot;write*:mod:ext3&quot; &gt; /sys/kernel/tracing/stack_trace_filter The current mod command causes a null pointer dereference. While commit 0f17976568b3f (&quot;ftrace: Fix regression with module command in stack_trace_filter&quot;) has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56569 CVE - 2024-56569 ELSA-2025-20095 ELSA-2025-20100

Debian: CVE-2024-56576: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: i2c: tc358743: Fix crash in the probe error path when using polling If an error occurs in the probe() function, we should remove the polling timer that was alarmed earlier, otherwise the timer is called with arguments that are already freed, which results in a crash. ------------[ cut here ]------------ WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268 Modules linked in: CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __run_timers+0x244/0x268 lr : __run_timers+0x1d4/0x268 sp : ffffff80eff2baf0 x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00 x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00 x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000 x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000 x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009 x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480 x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240 x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0 Call trace: __run_timers+0x244/0x268 timer_expire_remote+0x50/0x68 tmigr_handle_remote+0x388/0x39c run_timer_softirq+0x38/0x44 handle_softirqs+0x138/0x298 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0x9c/0xcc el1_interrupt+0x48/0xc0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x7c/0x80 default_idle_call+0x34/0x68 do_idle+0x23c/0x294 cpu_startup_entry+0x38/0x3c secondary_start_kernel+0x128/0x160 __secondary_switched+0xb8/0xbc ---[ end trace 0000000000000000 ]--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56576 CVE - 2024-56576

Debian: CVE-2024-56593: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw() This patch fixes a NULL pointer dereference bug in brcmfmac that occurs when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs are sent from the pkt queue. The problem is the number of entries in the pre-allocated sgtable, it is nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1. Given the default [rt]xglom_size=32 it's actually 35 which is too small. Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB is added for each original SKB if tailroom isn't enough to hold tail_pad. At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop" in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return NULL and this causes the oops. The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle the worst-case. Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464 additional bytes of memory. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56593 CVE - 2024-56593

Debian: CVE-2024-56567: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: ad7780: fix division by zero in ad7780_write_raw() In the ad7780_write_raw() , val2 can be zero, which might lead to a division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw() is based on iio_info's write_raw. While val is explicitly declared that can be zero (in read mode), val2 is not specified to be non-zero. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56567 CVE - 2024-56567