CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48745 – net/mlx5: Use del_timer_sync in fw reset flow of halting poll
https://notcve.org/view.php?id=CVE-2022-48745
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Use del_timer_sync in fw reset flow of halting poll Substitute del_timer() with del_timer_sync() in fw reset polling deactivation flow, in order to prevent a race condition which occurs when del_timer() is called and timer is deactivated while another process is handling the timer interrupt. A situation that led to the following call trace: RIP: 0010:run_timer_softirq+0x137/0x420 <IRQ> recalibrate_cpu_khz+0x10/0x10 ktime_get+0x3e/0xa0 ? sched_clock_cpu+0xb/0xc0 __do_softirq+0xf5/0x2ea irq_exit_rcu+0xc1/0xf0 sysvec_apic_timer_interrupt+0x9e/0xc0 asm_sysvec_apic_timer_interrupt+0x12/0x20 </IRQ> • https://git.kernel.org/stable/c/38b9f903f22b9baa5c4b9bfb07c8bbc49f5efbba https://git.kernel.org/stable/c/502c37b033fab7cde3e95a570af4f073306be45e https://git.kernel.org/stable/c/f895ebeb44d09d02674cfdd0cfc2bf687603918c https://git.kernel.org/stable/c/2a038dd1d942f8fbc495c58fa592ff24af05f1c2 https://git.kernel.org/stable/c/3c5193a87b0fea090aa3f769d020337662d87b5e •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48744 – net/mlx5e: Avoid field-overflowing memcpy()
https://notcve.org/view.php?id=CVE-2022-48744
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Avoid field-overflowing memcpy() In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use flexible arrays instead of zero-element arrays (which look like they are always overflowing) and split the cross-field memcpy() into two halves that can be appropriately bounds-checked by the compiler. We were doing: #define ETH_HLEN 14 #define VLAN_HLEN 4 ... #define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN) ... struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi); ... struct mlx5_wqe_eth_seg *eseg = &wqe->eth; struct mlx5_wqe_data_seg *dseg = wqe->data; ... memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE); target is wqe->eth.inline_hdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlan_tci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr (8 bytes). struct mlx5e_tx_wqe { struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */ struct mlx5_wqe_eth_seg eth; /* 16 16 */ struct mlx5_wqe_data_seg data[]; /* 32 0 */ /* size: 32, cachelines: 1, members: 3 */ /* last cacheline: 32 bytes */ }; struct mlx5_wqe_eth_seg { u8 swp_outer_l4_offset; /* 0 1 */ u8 swp_outer_l3_offset; /* 1 1 */ u8 swp_inner_l4_offset; /* 2 1 */ u8 swp_inner_l3_offset; /* 3 1 */ u8 cs_flags; /* 4 1 */ u8 swp_flags; /* 5 1 */ __be16 mss; /* 6 2 */ __be32 flow_table_metadata; /* 8 4 */ union { struct { __be16 sz; /* 12 2 */ u8 start[2]; /* 14 2 */ } inline_hdr; /* 12 4 */ struct { __be16 type; /* 12 2 */ __be16 vlan_tci; /* 14 2 */ } insert; /* 12 4 */ __be32 trailer; /* 12 4 */ }; /* 12 4 */ /* size: 16, cachelines: 1, members: 9 */ /* last cacheline: 16 bytes */ }; struct mlx5_wqe_data_seg { __be32 byte_count; /* 0 4 */ __be32 lkey; /* 4 4 */ __be64 addr; /* 8 8 */ /* size: 16, cachelines: 1, members: 3 */ /* last cacheline: 16 bytes */ }; So, split the memcpy() so the compiler can reason about the buffer sizes. "pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences and optimizations). • https://git.kernel.org/stable/c/b5503b994ed5ed8dbfe821317e7b5b38acb065c5 https://git.kernel.org/stable/c/8fbdf8c8b8ab82beab882175157650452c46493e https://git.kernel.org/stable/c/ad5185735f7dab342fdd0dd41044da4c9ccfef67 •
CVSS: 4.4EPSS: 0%CPEs: 10EXPL: 0CVE-2022-48743 – net: amd-xgbe: Fix skb data length underflow
https://notcve.org/view.php?id=CVE-2022-48743
In the Linux kernel, the following vulnerability has been resolved: net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. • https://git.kernel.org/stable/c/fafc9555d87a19c78bcd43ed731c3a73bf0b37a9 https://git.kernel.org/stable/c/622c36f143fc9566ba49d7cec994c2da1182d9e2 https://git.kernel.org/stable/c/ae43f9360a21b35cf785ae9a0fdce524d7af0938 https://git.kernel.org/stable/c/ae9d577f3dbb686862b7d0dc9cc73054f0964d4d https://git.kernel.org/stable/c/9924c80bd484340191e586110ca22bff23a49f2e https://git.kernel.org/stable/c/617f9934bb37993b9813832516f318ba874bcb7d https://git.kernel.org/stable/c/34aeb4da20f93ac80a6291a2dbe7b9c6460e9b26 https://git.kernel.org/stable/c/9892742f035f7aa7dcd2bb0750effa486 • CWE-124: Buffer Underwrite ('Buffer Underflow') •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48742 – rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()
https://notcve.org/view.php?id=CVE-2022-48742
In the Linux kernel, the following vulnerability has been resolved: rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink() While looking at one unrelated syzbot bug, I found the replay logic in __rtnl_newlink() to potentially trigger use-after-free. It is better to clear master_dev and m_ops inside the loop, in case we have to replay it. • https://git.kernel.org/stable/c/ba7d49b1f0f8e5f24294a880ed576964059af5ef https://git.kernel.org/stable/c/2cf180360d66bd657e606c1217e0e668e6faa303 https://git.kernel.org/stable/c/7d9211678c0f0624f74cdff36117ab8316697bb8 https://git.kernel.org/stable/c/a01e60a1ec6bef9be471fb7182a33c6d6f124e93 https://git.kernel.org/stable/c/bd43771ee9759dd9dfae946bff190e2c5a120de5 https://git.kernel.org/stable/c/3bbe2019dd12b8d13671ee6cda055d49637b4c39 https://git.kernel.org/stable/c/def5e7070079b2a214b3b1a2fbec623e6fbfe34a https://git.kernel.org/stable/c/36a9a0aee881940476b254e0352581401 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48741 – ovl: fix NULL pointer dereference in copy up warning
https://notcve.org/view.php?id=CVE-2022-48741
In the Linux kernel, the following vulnerability has been resolved: ovl: fix NULL pointer dereference in copy up warning This patch is fixing a NULL pointer dereference to get a recently introduced warning message working. • https://git.kernel.org/stable/c/5cffa333a2b263821561328cc75a3ffc8097d093 https://git.kernel.org/stable/c/5b0a414d06c3ed2097e32ef7944a4abb644b89bd https://git.kernel.org/stable/c/e6b678c1a3673de6a5d2f4e22bb725a086a0701a https://git.kernel.org/stable/c/9c7f8a35c5a83740c0e3ea540b6ad145c50d79aa https://git.kernel.org/stable/c/4ee7e4a6c9b298da44029ed9ec8ed23ae49cc209 •