CVSS: 5.2EPSS: 0%CPEs: 7EXPL: 0CVE-2024-41040 – net/sched: Fix UAF when resolving a clash
https://notcve.org/view.php?id=CVE-2024-41040
In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix UAF when resolving a clash KASAN reports the following UAF: BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] Read of size 1 at addr ffff888c07603600 by task handler130/6469 Call Trace: <IRQ> dump_stack_lvl+0x48/0x70 print_address_description.constprop.0+0x33/0x3d0 print_report+0xc0/0x2b0 kasan_report+0xd0/0x120 __asan_load1+0x6c/0x80 tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] tcf_ct_act+0x886/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 __irq_exit_rcu+0x82/0xc0 irq_exit_rcu+0xe/0x20 common_interrupt+0xa1/0xb0 </IRQ> <TASK> asm_common_interrupt+0x27/0x40 Allocated by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_alloc_info+0x1e/0x40 __kasan_krealloc+0x133/0x190 krealloc+0xaa/0x130 nf_ct_ext_add+0xed/0x230 [nf_conntrack] tcf_ct_act+0x1095/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 Freed by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_free_info+0x2b/0x60 ____kasan_slab_free+0x180/0x1f0 __kasan_slab_free+0x12/0x30 slab_free_freelist_hook+0xd2/0x1a0 __kmem_cache_free+0x1a2/0x2f0 kfree+0x78/0x120 nf_conntrack_free+0x74/0x130 [nf_conntrack] nf_ct_destroy+0xb2/0x140 [nf_conntrack] __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack] nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack] __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack] tcf_ct_act+0x12ad/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 The ct may be dropped if a clash has been resolved but is still passed to the tcf_ct_flow_table_process_conn function for further usage. This issue can be fixed by retrieving ct from skb again after confirming conntrack. • https://git.kernel.org/stable/c/f07c548314776231f0d47d73ec6caa5b17e876e8 https://git.kernel.org/stable/c/0cc254e5aa37cf05f65bcdcdc0ac5c58010feb33 https://git.kernel.org/stable/c/30822781c89943b6a3ed122324ceb37cea7042a3 https://git.kernel.org/stable/c/b81a523d54ea689414f67c9fb81a5b917a41ed55 https://git.kernel.org/stable/c/2b4d68df3f57ea746c430941ba9c03d7d8b5a23f https://git.kernel.org/stable/c/4e71b10a100861fb27d9c5755dfd68f615629fae https://git.kernel.org/stable/c/799a34901b634008db4a7ece3900e2b971d4c932 https://git.kernel.org/stable/c/ef472cc6693b16b202a916482df72f35d • CWE-416: Use After Free •
CVSS: 5.2EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41039 – firmware: cs_dsp: Fix overflow checking of wmfw header
https://notcve.org/view.php?id=CVE-2024-41039
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Fix overflow checking of wmfw header Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer. The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs wmfw_header + wmfw_adsp1_sizes + wmfw_footer But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfw_adsp2_sizes, which is 4 bytes longer. So the length check didn't guarantee that there are enough bytes in the firmware buffer for a header with wmfw_adsp2_sizes. This patch splits the length check into three separate parts. Each of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked separately before they are used. • https://git.kernel.org/stable/c/f6bc909e7673c30abcbdb329e7d0aa2e83c103d7 https://git.kernel.org/stable/c/fd035f0810b33c2a8792effdb82bf35920221565 https://git.kernel.org/stable/c/9c9877a96e033bf6c6470b3b4f06106d91ace11e https://git.kernel.org/stable/c/49a79f344d0a17c6a5eef53716cc76fcdbfca9ba https://git.kernel.org/stable/c/3019b86bce16fbb5bc1964f3544d0ce7d0137278 https://access.redhat.com/security/cve/CVE-2024-41039 https://bugzilla.redhat.com/show_bug.cgi?id=2300408 • CWE-122: Heap-based Buffer Overflow •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41038 – firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers
https://notcve.org/view.php?id=CVE-2024-41038
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers Check that all fields of a V2 algorithm header fit into the available firmware data buffer. The wmfw V2 format introduced variable-length strings in the algorithm block header. This means the overall header length is variable, and the position of most fields varies depending on the length of the string fields. Each field must be checked to ensure that it does not overflow the firmware data buffer. As this ia bugfix patch, the fixes avoid making any significant change to the existing code. This makes it easier to review and less likely to introduce new bugs. • https://git.kernel.org/stable/c/f6bc909e7673c30abcbdb329e7d0aa2e83c103d7 https://git.kernel.org/stable/c/6619aa48a011364e9f29083cc76368e6acfe5b11 https://git.kernel.org/stable/c/76ea8e13aaefdfda6e5601323d6ea5340359dcfa https://git.kernel.org/stable/c/014239b9971d79421a0ba652579e1ca1b7b57b6d https://git.kernel.org/stable/c/2163aff6bebbb752edf73f79700f5e2095f3559e https://access.redhat.com/security/cve/CVE-2024-41038 https://bugzilla.redhat.com/show_bug.cgi?id=2300407 • CWE-122: Heap-based Buffer Overflow •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-41037 – ASoC: SOF: Intel: hda: fix null deref on system suspend entry
https://notcve.org/view.php?id=CVE-2024-41037
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda: fix null deref on system suspend entry When system enters suspend with an active stream, SOF core calls hw_params_upon_resume(). On Intel platforms with HDA DMA used to manage the link DMA, this leads to call chain of hda_dsp_set_hw_params_upon_resume() -> hda_dsp_dais_suspend() -> hda_dai_suspend() -> hda_ipc4_post_trigger() A bug is hit in hda_dai_suspend() as hda_link_dma_cleanup() is run first, which clears hext_stream->link_substream, and then hda_ipc4_post_trigger() is called with a NULL snd_pcm_substream pointer. • https://git.kernel.org/stable/c/2b009fa0823c1510700fd17a0780ddd06a460fb4 https://git.kernel.org/stable/c/8246bbf818ed7b8d5afc92b951e6d562b45c2450 https://git.kernel.org/stable/c/993af0f2d9f24e3c18a445ae22b34190d1fcad61 https://git.kernel.org/stable/c/9065693dcc13f287b9e4991f43aee70cf5538fdd •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-41036 – net: ks8851: Fix deadlock with the SPI chip variant
https://notcve.org/view.php?id=CVE-2024-41036
In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Fix deadlock with the SPI chip variant When SMP is enabled and spinlocks are actually functional then there is a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi and ks8851_irq: watchdog: BUG: soft lockup - CPU#0 stuck for 27s! call trace: queued_spin_lock_slowpath+0x100/0x284 do_raw_spin_lock+0x34/0x44 ks8851_start_xmit_spi+0x30/0xb8 ks8851_start_xmit+0x14/0x20 netdev_start_xmit+0x40/0x6c dev_hard_start_xmit+0x6c/0xbc sch_direct_xmit+0xa4/0x22c __qdisc_run+0x138/0x3fc qdisc_run+0x24/0x3c net_tx_action+0xf8/0x130 handle_softirqs+0x1ac/0x1f0 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x3c/0x58 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x54/0x9c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 __netif_schedule+0x6c/0x80 netif_tx_wake_queue+0x38/0x48 ks8851_irq+0xb8/0x2c8 irq_thread_fn+0x2c/0x74 irq_thread+0x10c/0x1b0 kthread+0xc8/0xd8 ret_from_fork+0x10/0x20 This issue has not been identified earlier because tests were done on a device with SMP disabled and so spinlocks were actually NOPs. Now use spin_(un)lock_bh for TX queue related locking to avoid execution of softirq work synchronously that would lead to a deadlock. • https://git.kernel.org/stable/c/1092525155eaad5c69ca9f3b6f3e7895a9424d66 https://git.kernel.org/stable/c/30302b41ffdcd194bef27fb3b1a9f2ca53dedb27 https://git.kernel.org/stable/c/3dc5d44545453de1de9c53cc529cc960a85933da https://git.kernel.org/stable/c/786788bb1396ed5ea27e39c4933f59f4e52004e4 https://git.kernel.org/stable/c/7c25c5d7274631b655f0f9098a16241fcd5db57b https://git.kernel.org/stable/c/a0c69c492f4a8fad52f0a97565241c926160c9a4 https://git.kernel.org/stable/c/80ece00137300d74642f2038c8fe5440deaf9f05 https://git.kernel.org/stable/c/10fec0cd0e8f56ff06c46bb24254c7d8f •