mirror of
git://slackware.nl/current.git
synced 2024-12-29 10:25:00 +01:00
694953a024
patches/packages/glibc-zoneinfo-2023b-noarch-1_slack15.0.txz: Upgraded.
This package provides the latest timezone updates.
patches/packages/tar-1.34-x86_64-2_slack15.0.txz: Rebuilt.
GNU Tar through 1.34 has a one-byte out-of-bounds read that results in use
of uninitialized memory for a conditional jump. Exploitation to change the
flow of control has not been demonstrated. The issue occurs in from_header
in list.c via a V7 archive in which mtime has approximately 11 whitespace
characters.
Thanks to marav for the heads-up.
For more information, see:
https://www.cve.org/CVERecord?id=CVE-2022-48303
(* Security fix *)
31 lines
1.1 KiB
Diff
31 lines
1.1 KiB
Diff
--- ./src/list.c.orig 2017-12-16 15:23:12.000000000 -0600
|
|
+++ ./src/list.c 2018-09-06 16:51:52.982740004 -0500
|
|
@@ -242,15 +242,22 @@
|
|
|
|
if (!ignore_zeros_option)
|
|
{
|
|
- char buf[UINTMAX_STRSIZE_BOUND];
|
|
+
|
|
+ /*
|
|
+ * According to POSIX tar specs, this is wrong, but on the web
|
|
+ * there are some tar specs that can trigger this, and some tar
|
|
+ * implementations create tars according to that spec. For now,
|
|
+ * let's not be pedantic about issuing the warning.
|
|
+ *
|
|
+ * char buf[UINTMAX_STRSIZE_BOUND]; */
|
|
|
|
status = read_header (¤t_header, ¤t_stat_info,
|
|
read_header_auto);
|
|
- if (status == HEADER_ZERO_BLOCK)
|
|
- break;
|
|
- WARNOPT (WARN_ALONE_ZERO_BLOCK,
|
|
- (0, 0, _("A lone zero block at %s"),
|
|
- STRINGIFY_BIGINT (current_block_ordinal (), buf)));
|
|
+ /* if (status == HEADER_ZERO_BLOCK)
|
|
+ * break;
|
|
+ * WARNOPT (WARN_ALONE_ZERO_BLOCK,
|
|
+ * (0, 0, _("A lone zero block at %s"),
|
|
+ * STRINGIFY_BIGINT (current_block_ordinal (), buf))); */
|
|
break;
|
|
}
|
|
status = prev_status;
|