A flaw was found in rsync. This vulnerability arises from a race condition during
rsync's handling of symbolic links. Rsync's default behavior when encountering
symbolic links is to skip them. If an attacker replaced a regular file with a
symbolic link at the right time, it was possible to bypass the default behavior
and traverse symbolic links. Depending on the privileges of the rsync process,
an attacker could leak sensitive information, potentially leading to privilege escalation.
(From OE-Core rev: c0905ffb2f1aa3bc4c6187ff4860dcc8d3dbfb01)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in rsync. When using the `--safe-links` option, rsync fails to
properly verify if a symbolic link destination contains another symbolic link within it.
This results in a path traversal vulnerability, which may lead to arbitrary file write
outside the desired directory
(From OE-Core rev: 741200c41a19ef5b4876d9a80667dfde2e5f4a9d)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A path traversal vulnerability exists in rsync. It stems from behavior enabled
by the `--inc-recursive` option, a default-enabled option for many client options
and can be enabled by the server even if not explicitly enabled by the client.
When using the `--inc-recursive` option, a lack of proper symlink verification
coupled with deduplication checks occurring on a per-file-list basis could allow
a server to write files outside of the client's intended destination directory.
A malicious server could write malicious files to arbitrary locations named after
valid directories/paths on the client.
(From OE-Core rev: 12328df8dfcdc73ef70af299e9ebdc1d8ae73f37)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in rsync. It could allow a server to enumerate the contents of an
arbitrary file from the client's machine. This issue occurs when files are being
copied from a client to a server. During this process, the rsync server will send
checksums of local data to the client to compare with in order to determine what
data needs to be sent to the server. By sending specially constructed checksum values
for arbitrary files, an attacker may be able to reconstruct the data of those files
byte-by-byte based on the responses from the client.
(From OE-Core rev: b49c8f58c20d7deb354a86a34488cb798c49eba3)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in the rsync daemon which could be triggered when rsync compares
file checksums. This flaw allows an attacker to manipulate the checksum length
(s2length) to cause a comparison between a checksum and uninitialized memory and
leak one byte of uninitialized stack data at a time.
(From OE-Core rev: 3fd8bea3e72573cca03cd3f6f4fc077cd2fd45a3)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A heap-based buffer overflow flaw was found in the rsync daemon. This issue is due
to improper handling of attacker-controlled checksum lengths (s2length) in the code.
When MAX_DIGEST_LEN exceeds the fixed SUM_LENGTH (16 bytes), an attacker can write
out of bounds in the sum2 buffer.
(From OE-Core rev: 17fac276e27af19b00b6263f22156a55bae6a5c9)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This helps in building rsync without autoconf patch, since it will be a
while that the round trip is made, better to apply this patch here until
next release of autoconf.
(From OE-Core rev: 11522b98697befcf13076a90cec4f8ade1fa0645)
(From OE-Core rev: 3eeab90fd45a1e8de6d9d16dfdec79c72639614b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 8d6b8fb086)
Signed-off-by: pawan <badganchipv@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mark the path as submitted and effectively a backport as a different fix
was added upstream addressing the issue.
(From OE-Core rev: 6e82c6e1543f1e863b22d94652c90ee46b40f68a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop all CVE patches, add the new configure options.
(From OE-Core rev: d0249eeeeeb951bfcf7606563c0cde02d49f200d)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream some well intended but broken logic to reimplement the rebuild
functionality of automake. However this isn't out-of-tree safe and quite basic,
which means if it ever does execute (say, configure.ac or aclocal.m4 is touched)
then the build fails.
As we delete ${B} and re-run autoreconf on every build this is redundant, so
just delete it all.
[ YOCTO #9445 ]
(From OE-Core rev: ccc61cee8f097862640722abb9a9f53781efdac3)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This acinclude.m4 was actually a stale copy of upstream's generated aclocal.m4.
This generates correctly now, so there isn't a need to install this by hand
anymore.
(From OE-Core rev: 2d1948eb325bb769af97634f99efeffe3d43cfc9)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having one monolithic packages directory makes it hard to find things
and is generally overwhelming. This commit splits it into several
logical sections roughly based on function, recipes.txt gives more
information about the classifications used.
The opportunity is also used to switch from "packages" to "recipes"
as used in OpenEmbedded as the term "packages" can be confusing to
people and has many different meanings.
Not all recipes have been classified yet, this is just a first pass
at separating things out. Some packages are moved to meta-extras as
they're no longer actively used or maintained.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
