|
35 | 35 |
|
36 | 36 | <listitem> |
37 | 37 | <!-- |
| 38 | +Author: Michael Paquier <michael@paquier.xyz> |
| 39 | +Branch: master [71c37797d] 2023-02-06 11:20:07 +0900 |
| 40 | +Branch: REL_15_STABLE [715c345dd] 2023-02-06 11:20:20 +0900 |
| 41 | +Branch: REL_14_STABLE [626f2c1d6] 2023-02-06 11:20:23 +0900 |
| 42 | +Branch: REL_13_STABLE [45a945ee9] 2023-02-06 11:20:27 +0900 |
| 43 | +Branch: REL_12_STABLE [3f7342671] 2023-02-06 11:20:31 +0900 |
| 44 | +--> |
| 45 | + <para> |
| 46 | + <application>libpq</application> can leak memory contents after |
| 47 | + GSSAPI transport encryption initiation fails (Jacob Champion) |
| 48 | + </para> |
| 49 | + |
| 50 | + <para> |
| 51 | + A modified server, or an unauthenticated man-in-the-middle, can |
| 52 | + send a not-zero-terminated error message during setup of GSSAPI |
| 53 | + (Kerberos) transport encryption. <application>libpq</application> |
| 54 | + will then copy that string, as well as following bytes in |
| 55 | + application memory up to the next zero byte, to its error report. |
| 56 | + Depending on what the calling application does with the error |
| 57 | + report, this could result in disclosure of application memory |
| 58 | + contents. There is also a small probability of a crash due to |
| 59 | + reading beyond the end of memory. Fix by properly zero-terminating |
| 60 | + the server message. |
| 61 | + (CVE-2022-41862) |
| 62 | + </para> |
| 63 | + </listitem> |
| 64 | + |
| 65 | + <listitem> |
| 66 | +<!-- |
38 | 67 | Author: Tom Lane <tgl@sss.pgh.pa.us> |
39 | 68 | Branch: master [3f7836ff6] 2023-01-05 14:12:17 -0500 |
40 | 69 | Branch: REL_15_STABLE [3706cc97a] 2023-01-05 14:12:17 -0500 |
|