CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56722 – RDMA/hns: Fix cpu stuck caused by printings during reset
https://notcve.org/view.php?id=CVE-2024-56722
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix cpu stuck caused by printings during reset During reset, cmd to destroy resources such as qp, cq, and mr may fail, and error logs will be printed. When a large number of resources are destroyed, there will be lots of printings, and it may lead to a cpu stuck. Delete some unnecessary printings and replace other printing functions in these paths with the ratelimited version. • https://git.kernel.org/stable/c/9a4435375cd151e07c0c38fa601b00115986091b https://git.kernel.org/stable/c/31c6fe9b79ed42440094f2367897aea0c0ce96ec https://git.kernel.org/stable/c/b4ba31e5aaffbda9b22d9a35c40b16dc39e475a6 https://git.kernel.org/stable/c/a0e4c78770faa0d56d47391476fe1d827e72eded https://git.kernel.org/stable/c/e2e64f9c42c717beb459ab209ec1c4baa73d3760 https://git.kernel.org/stable/c/323275ac2ff15b2b7b3eac391ae5d8c5a3c3a999 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56720 – bpf, sockmap: Several fixes to bpf_msg_pop_data
https://notcve.org/view.php?id=CVE-2024-56720
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Several fixes to bpf_msg_pop_data Several fixes to bpf_msg_pop_data, 1. In sk_msg_shift_left, we should put_page 2. if (len == 0), return early is better 3. pop the entire sk_msg (last == msg->sg.size) should be supported 4. Fix for the value of variable "a" 5. In sk_msg_shift_left, after shifting, i has already pointed to the next element. Addtional sk_msg_iter_var_next may result in BUG. • https://git.kernel.org/stable/c/7246d8ed4dcce23f7509949a77be15fa9f0e3d28 https://git.kernel.org/stable/c/d3f5763b3062514a234114e97bbde74d8d702449 https://git.kernel.org/stable/c/d26d977633d1d0b8bf9407278189bd0a8d973323 https://git.kernel.org/stable/c/e1f54c61c4c9a5244eb8159dce60d248f7d97b32 https://git.kernel.org/stable/c/f58d3aa457e77a3d9b3df2ab081dcf9950f6029f https://git.kernel.org/stable/c/98c7ea7d11f2588e8197db042e0291e4ac8f8346 https://git.kernel.org/stable/c/785180bed9879680d8e5c5e1b54c8ae8d948f4c8 https://git.kernel.org/stable/c/275a9f3ef8fabb0cb282a62b9e164dedb •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-56719 – net: stmmac: fix TSO DMA API usage causing oops
https://notcve.org/view.php?id=CVE-2024-56719
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix TSO DMA API usage causing oops Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") moved the assignment of tx_skbuff_dma[]'s members to be later in stmmac_tso_xmit(). The buf (dma cookie) and len stored in this structure are passed to dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that the dma cookie passed to dma_unmap_single() is the same as the value returned from dma_map_single(). However, by moving the assignment later, this is not the case when priv->dma_cap.addr64 > 32 as "des" is offset by proto_hdr_len. This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed and with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes] Fix this by maintaining "des" as the original DMA cookie, and use tso_des to pass the offset DMA cookie to stmmac_tso_allocator(). Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/ • https://git.kernel.org/stable/c/07c9c26e37542486e34d767505e842f48f29c3f6 https://git.kernel.org/stable/c/66600fac7a984dea4ae095411f644770b2561ede https://git.kernel.org/stable/c/ece593fc9c00741b682869d3f3dc584d37b7c9df https://git.kernel.org/stable/c/a3ff23f7c3f0e13f718900803e090fd3997d6bc9 https://git.kernel.org/stable/c/58d23d835eb498336716cca55b5714191a309286 https://git.kernel.org/stable/c/db3667c9bbfbbf5de98e6c9542f7e03fb5243286 https://git.kernel.org/stable/c/9d5dd7ccea1b46a9a7c6b3c2b9e5ed8864e185e2 https://git.kernel.org/stable/c/4c49f38e20a57f8abaebdf95b369295b1 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56718 – net/smc: protect link down work from execute after lgr freed
https://notcve.org/view.php?id=CVE-2024-56718
In the Linux kernel, the following vulnerability has been resolved: net/smc: protect link down work from execute after lgr freed link down work may be scheduled before lgr freed but execute after lgr freed, which may result in crash. So it is need to hold a reference before shedule link down work, and put the reference after work executed or canceled. The relevant crash call stack as follows: list_del corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smc_link_down_work [smc] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsem_down_write_slowpath+0x17e/0x470 smc_link_down_work+0x3c/0x60 [smc] process_one_work+0x1ac/0x350 worker_thread+0x49/0x2f0 ? rescuer_thread+0x360/0x360 kthread+0x118/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x1f/0x30 • https://git.kernel.org/stable/c/541afa10c126b6c22c2a805a559c70cc41fd156e https://git.kernel.org/stable/c/bec2f52866d511e94c1c37cd962e4382b1b1a299 https://git.kernel.org/stable/c/2627c3e8646932dfc7b9722c88c2e1ffcf7a9fb2 https://git.kernel.org/stable/c/841b1824750d3b8d1dc0a96b14db4418b952abbc https://git.kernel.org/stable/c/2b33eb8f1b3e8c2f87cfdbc8cc117f6bdfabc6ec •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56717 – net: mscc: ocelot: fix incorrect IFH SRC_PORT field in ocelot_ifh_set_basic()
https://notcve.org/view.php?id=CVE-2024-56717
In the Linux kernel, the following vulnerability has been resolved: net: mscc: ocelot: fix incorrect IFH SRC_PORT field in ocelot_ifh_set_basic() Packets injected by the CPU should have a SRC_PORT field equal to the CPU port module index in the Analyzer block (ocelot->num_phys_ports). The blamed commit copied the ocelot_ifh_set_basic() call incorrectly from ocelot_xmit_common() in net/dsa/tag_ocelot.c. Instead of calling with "x", it calls with BIT_ULL(x), but the field is not a port mask, but rather a single port index. [ side note: this is the technical debt of code duplication :( ] The error used to be silent and doesn't appear to have other user-visible manifestations, but with new changes in the packing library, it now fails loudly as follows: ------------[ cut here ]------------ Cannot store 0x40 inside bits 46-43 - will truncate sja1105 spi2.0: xmit timed out WARNING: CPU: 1 PID: 102 at lib/packing.c:98 __pack+0x90/0x198 sja1105 spi2.0: timed out polling for tstamp CPU: 1 UID: 0 PID: 102 Comm: felix_xmit Tainted: G W N 6.13.0-rc1-00372-gf706b85d972d-dirty #2605 Call trace: __pack+0x90/0x198 (P) __pack+0x90/0x198 (L) packing+0x78/0x98 ocelot_ifh_set_basic+0x260/0x368 ocelot_port_inject_frame+0xa8/0x250 felix_port_deferred_xmit+0x14c/0x258 kthread_worker_fn+0x134/0x350 kthread+0x114/0x138 The code path pertains to the ocelot switchdev driver and to the felix secondary DSA tag protocol, ocelot-8021q. Here seen with ocelot-8021q. The messenger (packing) is not really to blame, so fix the original commit instead. • https://git.kernel.org/stable/c/06bcb9032e05ad717f9fd0a6e2fd3ae7f430fa31 https://git.kernel.org/stable/c/ff7f554bbd75d5cbf00cded81d05147c6617e876 https://git.kernel.org/stable/c/e1b9e80236c540fa85d76e2d510d1b38e1968c5d https://git.kernel.org/stable/c/be3a532167dd562ec38900c846e7ae6cc39aa2f1 https://git.kernel.org/stable/c/59c4ca8d8d7918eb6e2df91d2c254827264be309 https://git.kernel.org/stable/c/2f3c62ffe88116cd2a39cd73e01103535599970f https://git.kernel.org/stable/c/a8836eae3288c351acd3b2743d2fad2a4ee2bd56 https://git.kernel.org/stable/c/2d5df3a680ffdaf606baa10636bdb1daf •