Pretty much any kernel bug gets a CVE by default now, right?

wjholden 3 hours ago | parent | next [-]

Is that all there is here? The quantifier "several" did not prepare me for the wall of CVE numbers in this list.

	▲	vdfs 2 hours ago \| parent [-]
		https://docs.kernel.org/process/cve.html states that because almost any kernel bug can potentially compromise system security, the CVE team acts with extreme caution and labels nearly all bug fixes with a CVE

▲

seba_dos1 2 hours ago | parent | prev | next [-]

Yes. It looks funny, but it's a nothing burger.

▲

slopinthebag 2 hours ago | parent | prev [-]

yes because the majority are memory safety issues, and it's automatically assumed that a memory safety bug can lead to a vuln

one again illustrating the importance of encapsulating unsafe behavior. perhaps c should get a __UNSAFE { } block, where memory access is encapsulated and thus most bugs occurring outside of those blocks do not need to be marked as CVEs.

▲

akersten 2 hours ago | parent [-]

> perhaps c should get a __UNSAFE { } block,

I think the convention for this is at the filesystem level and most programmers use the `.c` suffix to indicate it

▲

slopinthebag 2 hours ago | parent [-]

in that case we need a block of system memory marked as unsafe so i can run these programs in it encapsulated

perhaps we could call it a sedimentchest?

	▲	catlifeonmars an hour ago \| parent [-]
		I think that’s just called “memory”. Encapsulation is your machine.