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: 4EXPL: 0CVE-2022-48740 – selinux: fix double free of cond_list on error paths
https://notcve.org/view.php?id=CVE-2022-48740
In the Linux kernel, the following vulnerability has been resolved: selinux: fix double free of cond_list on error paths On error path from cond_read_list() and duplicate_policydb_cond_list() the cond_list_destroy() gets called a second time in caller functions, resulting in NULL pointer deref. Fix this by resetting the cond_list_len to 0 in cond_list_destroy(), making subsequent calls a noop. Also consistently reset the cond_list pointer to NULL after freeing. [PM: fix line lengths in the description] • https://git.kernel.org/stable/c/f446089a268c8fc6908488e991d28a9b936293db https://git.kernel.org/stable/c/70caa32e6d81f45f0702070c0e4dfe945e92fbd7 https://git.kernel.org/stable/c/7ed9cbf7ac0d4ed86b356e1b944304ae9ee450d4 https://git.kernel.org/stable/c/186edf7e368c40d06cf727a1ad14698ea67b74ad •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48739 – ASoC: hdmi-codec: Fix OOB memory accesses
https://notcve.org/view.php?id=CVE-2022-48739
In the Linux kernel, the following vulnerability has been resolved: ASoC: hdmi-codec: Fix OOB memory accesses Correct size of iec_status array by changing it to the size of status array of the struct snd_aes_iec958. This fixes out-of-bounds slab read accesses made by memcpy() of the hdmi-codec driver. This problem is reported by KASAN. • https://git.kernel.org/stable/c/10007bd96b6c4c3cfaea9e76c311b06a07a5e260 https://git.kernel.org/stable/c/1552e66be325a21d7eff49f46013fb402165a0ac https://git.kernel.org/stable/c/06feec6005c9d9500cd286ec440aabf8b2ddd94d •