Hi!

> ** Updated CVEs

> CVE-2021-22543: v4.19 and v5.10 are fixed. v4.4 uses another way to
> get pfn. If v4.4 is vulnerable it needs to write its own patch.

4.4 is very different in that area, and KVM is not exactly our
focus. A lot of research would be needed. I guess we can simply ignore
this one.

> * CVE detail
> 
> CVE-2021-35477: unprivileged BPF program can obtain sensitive
> information from kernel memory via a speculative store bypass
> side-channel attack because the technique used by the BPF verifier to
> manage speculation is unreliable
> 
> CVE-2021-34556 and CVE-2021-35477 are fixed by the same commits.
> commit 2039f26f3aca fixes af86ca4e3088(introduced by v4.17-rc7) and
> f7cf25b2026d(introduced by v5.3-rc1).
> 
> Fixed status
> mainline: [f5e81d1117501546b7be050c5fbafa6efd2c722c,
> 2039f26f3aca5b0e419b98f65dd36481337b86ee]
> stable/5.10: [bea9e2fd180892eba2574711b05b794f1d0e7b73,
> 0e9280654aa482088ee6ef3deadef331f5ac5fb0]
> stable/5.13: [ddab060f996e17b38bb181c5fd11a83fd1bfa0df,
> 0b27bdf02c400684225ee5ee99970bcbf5082282]

Yes, speculation is huge problem, and getting BPF right with broken
CPUs will be hard. I'd hope CIP people are not using untrusted BTF
programs, and that we can ignore it.

> CVE-2021-3669: reading /proc/sysvipc/shm does not scale with large
> shared memory segment counts
> 
> According to redhat bugzilla, it said "Not reported upstream, patches
> are being worked on.  It is not considered high impact because of the
> requirements and need to have massive amount of shm (usually well
> above ulimits) ".
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1986473#c10

DoS only, and only in unusual configuration. I believe we can ignore
this one.

> CVE-2021-37159: hso_free_net_device in drivers/net/usb/hso.c in the
> Linux kernel through 5.13.4 calls unregister_netdev without checking
> for the NETREG_REGISTERED state, leading to a use-after-free and a
> double free.
> 
> The mainline, 5.10, 5.13 are fixed.
> 
> Fixed status
> mainline: [a6ecfb39ba9d7316057cea823b196b734f6b18ca]
> stable/5.10: [115e4f5b64ae8d9dd933167cafe2070aaac45849]
> stable/5.13: [eeaa4b8d1e2e6f10362673d283a97dccc7275afa]

I guess we could try to rework the function in similar way 5.10 did,
but... we are not using HSO in our configs, and I have hard time
imagining how "attacker" would trigger it. So this is... just a
bug. I'd suggest ignoring.

Best regards,
								Pavel

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany