CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48746 – net/mlx5e: Fix handling of wrong devices during bond netevent
https://notcve.org/view.php?id=CVE-2022-48746
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix handling of wrong devices during bond netevent Current implementation of bond netevent handler only check if the handled netdev is VF representor and it missing a check if the VF representor is on the same phys device of the bond handling the netevent. Fix by adding the missing check and optimizing the check if the netdev is VF representor so it will not access uninitialized private data and crashes. BUG: kernel NULL pointer dereference, address: 000000000000036c PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI Workqueue: eth3bond0 bond_mii_monitor [bonding] RIP: 0010:mlx5e_is_uplink_rep+0xc/0x50 [mlx5_core] RSP: 0018:ffff88812d69fd60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8881cf800000 RCX: 0000000000000000 RDX: ffff88812d69fe10 RSI: 000000000000001b RDI: ffff8881cf800880 RBP: ffff8881cf800000 R08: 00000445cabccf2b R09: 0000000000000008 R10: 0000000000000004 R11: 0000000000000008 R12: ffff88812d69fe10 R13: 00000000fffffffe R14: ffff88820c0f9000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88846fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036c CR3: 0000000103d80006 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5e_eswitch_uplink_rep+0x31/0x40 [mlx5_core] mlx5e_rep_is_lag_netdev+0x94/0xc0 [mlx5_core] mlx5e_rep_esw_bond_netevent+0xeb/0x3d0 [mlx5_core] raw_notifier_call_chain+0x41/0x60 call_netdevice_notifiers_info+0x34/0x80 netdev_lower_state_changed+0x4e/0xa0 bond_mii_monitor+0x56b/0x640 [bonding] process_one_work+0x1b9/0x390 worker_thread+0x4d/0x3d0 ? rescuer_thread+0x350/0x350 kthread+0x124/0x150 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 • https://git.kernel.org/stable/c/7e51891a237f9ea319f53f9beb83afb0077d88e6 https://git.kernel.org/stable/c/a01ee1b8165f4161459b5ec4e728bc7130fe8cd4 https://git.kernel.org/stable/c/fe70126da6063c29ca161cdec7ad1dae9af836b3 https://git.kernel.org/stable/c/4fad499d7fece448e7230d5e5b92f6d8a073e0bb https://git.kernel.org/stable/c/ec41332e02bd0acf1f24206867bb6a02f5877a62 •
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: 5.3EPSS: 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 •