| Message ID | 20230817213302.51341-1-yuxuan.luo@canonical.com |
|---|---|
| Headers | show |
| Series | CVE-2023-4273 | expand |
On 17.08.23 23:33, Yuxuan Luo wrote: > [Impact] > A flaw was found in the exFAT driver of the Linux kernel. The > vulnerability exists in the implementation of the file name > reconstruction function, which is responsible for reading file name > entries from a directory index and merging file name parts belonging to > one file into a single long file name. Since the file name characters > are copied into a stack variable, a local privileged attacker could use > this flaw to overflow the kernel stack. > > [Backport] > It is a clean cherry pick on Lunar. > For Jammy and OEM kernels, there are two conflicts, `int i, err;` line > and `struct ... es;` line, which requires commits 8258ef28001a (“exfat: > handle unreconized benign secondary entries”) and 20914ff6dd56 (“exfat: > move exfat_entry_set_cache from heap to stack”) respectively. However, > they are not relevant to this fix, ignore them and backport the fix > manually. > > [Test] > Tested via mounting exfat file system and rename a file with a very long name. > > [Potential Regression] > Expect very low regression potential. > > > Namjae Jeon (1): > exfat: check if filename entries exceeds max filename length > > fs/exfat/dir.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > The backport appears to be context adjustments (that might be a better reason text than the one used). Also, if I could convince you on a slight change on your subject lines. Instead of Jammy-OEM.* just write OEM.*? Those kernels only exist in a certain series (like HWE.*) and spelling it out can cause confusion whether you mean jammy:linux as well. The earlier the morning the harder to spot. Acked-by: Stefan Bader <stefan.bader@canonical.com>
On 8/17/23 3:33 PM, Yuxuan Luo wrote: > [Impact] > A flaw was found in the exFAT driver of the Linux kernel. The > vulnerability exists in the implementation of the file name > reconstruction function, which is responsible for reading file name > entries from a directory index and merging file name parts belonging to > one file into a single long file name. Since the file name characters > are copied into a stack variable, a local privileged attacker could use > this flaw to overflow the kernel stack. > > [Backport] > It is a clean cherry pick on Lunar. > For Jammy and OEM kernels, there are two conflicts, `int i, err;` line > and `struct ... es;` line, which requires commits 8258ef28001a (“exfat: > handle unreconized benign secondary entries”) and 20914ff6dd56 (“exfat: > move exfat_entry_set_cache from heap to stack”) respectively. However, > they are not relevant to this fix, ignore them and backport the fix > manually. > > [Test] > Tested via mounting exfat file system and rename a file with a very long name. > > [Potential Regression] > Expect very low regression potential. > > > Namjae Jeon (1): > exfat: check if filename entries exceeds max filename length > > fs/exfat/dir.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > Acked-by: Tim Gardner <tim.gardner@canonical.com>
Yuxuan Luo kirjoitti 18.8.2023 klo 0.33: > [Impact] > A flaw was found in the exFAT driver of the Linux kernel. The > vulnerability exists in the implementation of the file name > reconstruction function, which is responsible for reading file name > entries from a directory index and merging file name parts belonging to > one file into a single long file name. Since the file name characters > are copied into a stack variable, a local privileged attacker could use > this flaw to overflow the kernel stack. > > [Backport] > It is a clean cherry pick on Lunar. > For Jammy and OEM kernels, there are two conflicts, `int i, err;` line > and `struct ... es;` line, which requires commits 8258ef28001a (“exfat: > handle unreconized benign secondary entries”) and 20914ff6dd56 (“exfat: > move exfat_entry_set_cache from heap to stack”) respectively. However, > they are not relevant to this fix, ignore them and backport the fix > manually. > > [Test] > Tested via mounting exfat file system and rename a file with a very long name. > > [Potential Regression] > Expect very low regression potential. > > > Namjae Jeon (1): > exfat: check if filename entries exceeds max filename length > > fs/exfat/dir.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > applied to oem kernels, thanks
On 17.08.23 23:33, Yuxuan Luo wrote: > [Impact] > A flaw was found in the exFAT driver of the Linux kernel. The > vulnerability exists in the implementation of the file name > reconstruction function, which is responsible for reading file name > entries from a directory index and merging file name parts belonging to > one file into a single long file name. Since the file name characters > are copied into a stack variable, a local privileged attacker could use > this flaw to overflow the kernel stack. > > [Backport] > It is a clean cherry pick on Lunar. > For Jammy and OEM kernels, there are two conflicts, `int i, err;` line > and `struct ... es;` line, which requires commits 8258ef28001a (“exfat: > handle unreconized benign secondary entries”) and 20914ff6dd56 (“exfat: > move exfat_entry_set_cache from heap to stack”) respectively. However, > they are not relevant to this fix, ignore them and backport the fix > manually. > > [Test] > Tested via mounting exfat file system and rename a file with a very long name. > > [Potential Regression] > Expect very low regression potential. > > > Namjae Jeon (1): > exfat: check if filename entries exceeds max filename length > > fs/exfat/dir.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > Applied to lunar,jammy:linux/master-next. Thanks. -Stefan