<div dir="ltr">Hello people,<div><br></div><div>I am kind of new to this kind of mailing list, so do not hesitate to indicate to me if I have any inappropriate behavior (even if I hope it should not be the case).</div><div><br></div><div>I recently came upon Java and Java security related aspects, mostly around the SecurityManager and what orbits around.</div><div>To be precise, I am currently analysing old exploits against the Java sandbox, and trying to understand how freshly discovered exploits within the Java core libraries could be implemented. A logic thought made me search for recently applied patches for high severity CVSS targeting the Java core libraries.</div><div>So, I came to the CVE CVE-2020-2803 and CVE-2020-2805. However, when observing the two associated patches, I wonder if these are really exploitable, and more generally, who and what is the process which decides the CVSS score of this kind of vulnerability.</div><div><br></div><div>I explain myself : on the patch for CVE-2020-2803, one can see the position and limit variables are not relatively checked when creating a new *Buffer within the "slice" method. This indeed leads to a potentially undefined behavior. However, the only objects on which this can have an impact are, correctly if I am wrong, the associated native java arrays (like the double hb[] array for HeapDoubleBuffer).</div><div>And there is no chance any dangerous effect comes from there, as an OutOfBoundException will be raised if any bound is wrong at the end.</div><div>It would have been different if the same principle can be applied to Direct*Buffer, as these seem to have more impact on raw memory. However, these buffers are not vulnerable in their splice method due to the checks being performed.</div><div>Am I right for this one ?</div><div><br></div><div>Concerning the CVE-2020-2805, I must admit I am less confident of what I say regarding the previous one. For me, the patch gives the impression to force a certain MethodType to be in cache instead of "letting" the rtype and ptypes variables possibly being externally modified before readResolve is called (leading to the potential mentioned impact).</div><div>However, I don't see any way of how these attributes could be modified between the call to ReadObject and the following call to ReadResolve, which should be performed immediately after.</div><div><br></div><div>I may be wrong on both points, and I would be really grateful if someone could explain why these 2 CVE have been rated this high whereas at first glance there isn't any really exploitable related scenario.</div><div><br></div><div>Regards,</div><div>--</div><div>Rick</div></div>