mirror of
git://git.openembedded.org/meta-openembedded
synced 2026-01-04 16:10:10 +00:00
Bug fix only updates. see: https://raw.githubusercontent.com/antirez/redis/5.0/00-RELEASENOTES Including these cves: 5.0.14 Security Fixes: * (CVE-2021-41099) Integer to heap buffer overflow handling certain string commands and network payloads, when proto-max-bulk-len is manually configured to a non-default, very large value [reported by yiyuaner]. * (CVE-2021-32762) Integer to heap buffer overflow issue in redis-cli and redis-sentinel parsing large multi-bulk replies on some older and less common platforms [reported by Microsoft Vulnerability Research]. * (CVE-2021-32687) Integer to heap buffer overflow with intsets, when set-max-intset-entries is manually configured to a non-default, very large value [reported by Pawel Wieczorkiewicz, AWS]. * (CVE-2021-32675) Denial Of Service when processing RESP request payloads with a large number of elements on many connections. * (CVE-2021-32672) Random heap reading issue with Lua Debugger [reported by Meir Shpilraien]. * (CVE-2021-32628) Integer to heap buffer overflow handling ziplist-encoded data types, when configuring a large, non-default value for hash-max-ziplist-entries, hash-max-ziplist-value, zset-max-ziplist-entries or zset-max-ziplist-value [reported by sundb]. * (CVE-2021-32627) Integer to heap buffer overflow issue with streams, when configuring a non-default, large value for proto-max-bulk-len and client-query-buffer-limit [reported by sundb]. * (CVE-2021-32626) Specially crafted Lua scripts may result with Heap buffer overflow [reported by Meir Shpilraien]. 5.0.11 Integer overflow on 32-bit systems (CVE-2021-21309): Redis 4.0 or newer uses a configurable limit for the maximum supported bulk input size. By default, it is 512MB which is a safe value for all platforms. If the limit is significantly increased, receiving a large request from a client may trigger several integer overflow scenarios, which would result with buffer overflow and heap corruption. 5.0.10 This release fixes a potential heap overflow when using a heap allocator other than jemalloc or glibc's malloc. See: https://github.com/redis/redis/pull/7963 Signed-off-by: Armin Kuster <akuster808@gmail.com> |
||
|---|---|---|
| .. | ||
| classes | ||
| conf | ||
| dynamic-layers | ||
| lib/oeqa/selftest/cases | ||
| licenses | ||
| recipes-benchmark | ||
| recipes-bsp | ||
| recipes-connectivity | ||
| recipes-core | ||
| recipes-crypto | ||
| recipes-dbs | ||
| recipes-devtools | ||
| recipes-extended | ||
| recipes-gnome | ||
| recipes-graphics | ||
| recipes-kernel | ||
| recipes-multimedia | ||
| recipes-navigation | ||
| recipes-printing | ||
| recipes-security | ||
| recipes-shells | ||
| recipes-support | ||
| recipes-test | ||
| COPYING.MIT | ||
| README | ||
meta-oe ======= This layer depends on: URI: git://github.com/openembedded/openembedded-core.git branch: dunfell revision: HEAD luajit recipe requires host compiler to be able to generate 32bit code when target is 32bit e.g. arm, so ensure that $CC -m32 is functional on build host, if building this recipe, needed packages to fullfit this might have different names on different host distributions e.g. on archlinux based distributions install prerequisites like below pacman -S lib32-gcc-libs lib32-glibc Ubuntu sudo apt-get install gcc-multilib Send pull requests to openembedded-devel@lists.openembedded.org with '[meta-oe][dunfell]' in the subject' When sending single patches, please use something like: 'git send-email -M -1 --to openembedded-devel@lists.openembedded.org --subject-prefix=meta-oe][dunfell][PATCH' You are encouraged to fork the mirror on GitHub https://github.com/openembedded/meta-openembedded to share your patches, this is preferred for patch sets consisting of more than one patch. Other services like GitLab, repo.or.cz or self-hosted setups are of course accepted as well, 'git fetch <remote>' works the same on all of them. We recommend GitHub because it is free, easy to use, has been proven to be reliable and has a really good web GUI. dunfell maintainer: Armin Kuster <akuster808@gmail.com>