ALT-BU-2024-10516-1
Branch sisyphus update bulletin.
Closed vulnerabilities
Modified: 2024-11-21
CVE-2021-3578
A flaw was found in mbsync before v1.3.6 and v1.4.2, where an unchecked pointer cast allows a malicious or compromised server to write an arbitrary integer value past the end of a heap-allocated structure by issuing an unexpected APPENDUID response. This could be plausibly exploited for remote code execution on the client.
- [oss-security] 20210607 CVE-2021-3578: possible remote code execution in isync/mbsync
- [oss-security] 20210607 CVE-2021-3578: possible remote code execution in isync/mbsync
- https://bugzilla.redhat.com/show_bug.cgi?id=1961710
- https://bugzilla.redhat.com/show_bug.cgi?id=1961710
- https://bugzilla.redhat.com/show_bug.cgi?id=1967397
- https://bugzilla.redhat.com/show_bug.cgi?id=1967397
- https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/
- https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/
- [debian-lts-announce] 20220701 [SECURITY] [DLA 3066-1] isync security update
- [debian-lts-announce] 20220701 [SECURITY] [DLA 3066-1] isync security update
- FEDORA-2021-754af4d52b
- FEDORA-2021-754af4d52b
- FEDORA-2021-f236f9f01a
- FEDORA-2021-f236f9f01a
- GLSA-202208-15
- GLSA-202208-15
- https://www.openwall.com/lists/oss-security/2021/06/07/1
- https://www.openwall.com/lists/oss-security/2021/06/07/1
Modified: 2024-11-21
CVE-2021-44143
A flaw was found in mbsync in isync 1.4.0 through 1.4.3. Due to an unchecked condition, a malicious or compromised IMAP server could use a crafted mail message that lacks headers (i.e., one that starts with an empty line) to provoke a heap overflow, which could conceivably be exploited for remote code execution.
- [oss-security] 20211203 CVE-2021-44143: heap overflow in isync/mbsync
- [oss-security] 20211203 CVE-2021-44143: heap overflow in isync/mbsync
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999804
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999804
- FEDORA-2021-577129851b
- FEDORA-2021-577129851b
- FEDORA-2021-b7fdb7e69a
- FEDORA-2021-b7fdb7e69a
- GLSA-202208-15
- GLSA-202208-15
- https://sourceforge.net/p/isync/isync/commit_browser
- https://sourceforge.net/p/isync/isync/commit_browser
- https://sourceforge.net/p/isync/isync/ref/master/tags/
- https://sourceforge.net/p/isync/isync/ref/master/tags/
Package kernel-image-mp updated to version 6.9.12-alt1 for branch sisyphus in task 353894.
Closed vulnerabilities
Modified: 2024-11-21
CVE-2024-41007
In the Linux kernel, the following vulnerability has been resolved: tcp: avoid too many retransmit packets If a TCP socket is using TCP_USER_TIMEOUT, and the other peer retracted its window to zero, tcp_retransmit_timer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCP_USER_TIMEOUT has 'expired'. The fix is to make sure tcp_rtx_probe0_timed_out() takes icsk->icsk_user_timeout into account. Before blamed commit, the socket would not timeout after icsk->icsk_user_timeout, but would use standard exponential backoff for the retransmits. Also worth noting that before commit e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0"), the issue would last 2 minutes instead of 4.
- https://git.kernel.org/stable/c/04317a2471c2f637b4c49cbd0e9c0d04a519f570
- https://git.kernel.org/stable/c/04317a2471c2f637b4c49cbd0e9c0d04a519f570
- https://git.kernel.org/stable/c/5d7e64d70a11d988553a08239c810a658e841982
- https://git.kernel.org/stable/c/5d7e64d70a11d988553a08239c810a658e841982
- https://git.kernel.org/stable/c/66cb64a1d2239cd0309f9b5038b05462570a5be1
- https://git.kernel.org/stable/c/66cb64a1d2239cd0309f9b5038b05462570a5be1
- https://git.kernel.org/stable/c/7bb7670f92bfbd05fc41a8f9a8f358b7ffed65f4
- https://git.kernel.org/stable/c/7bb7670f92bfbd05fc41a8f9a8f358b7ffed65f4
- https://git.kernel.org/stable/c/97a9063518f198ec0adb2ecb89789de342bb8283
- https://git.kernel.org/stable/c/97a9063518f198ec0adb2ecb89789de342bb8283
- https://git.kernel.org/stable/c/d2346fca5bed130dc712f276ac63450201d52969
- https://git.kernel.org/stable/c/d2346fca5bed130dc712f276ac63450201d52969
- https://git.kernel.org/stable/c/dfcdd7f89e401d2c6616be90c76c2fac3fa98fde
- https://git.kernel.org/stable/c/dfcdd7f89e401d2c6616be90c76c2fac3fa98fde
- https://git.kernel.org/stable/c/e113cddefa27bbf5a79f72387b8fbd432a61a466
- https://git.kernel.org/stable/c/e113cddefa27bbf5a79f72387b8fbd432a61a466
Modified: 2024-11-21
CVE-2024-41010
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix too early release of tcx_entry Pedro Pinto and later independently also Hyunwoo Kim and Wongi Lee reported an issue that the tcx_entry can be released too early leading to a use after free (UAF) when an active old-style ingress or clsact qdisc with a shared tc block is later replaced by another ingress or clsact instance. Essentially, the sequence to trigger the UAF (one example) can be as follows: 1. A network namespace is created 2. An ingress qdisc is created. This allocates a tcx_entry, and &tcx_entry->miniq is stored in the qdisc's miniqp->p_miniq. At the same time, a tcf block with index 1 is created. 3. chain0 is attached to the tcf block. chain0 must be connected to the block linked to the ingress qdisc to later reach the function tcf_chain0_head_change_cb_del() which triggers the UAF. 4. Create and graft a clsact qdisc. This causes the ingress qdisc created in step 1 to be removed, thus freeing the previously linked tcx_entry: rtnetlink_rcv_msg() => tc_modify_qdisc() => qdisc_create() => clsact_init() [a] => qdisc_graft() => qdisc_destroy() => __qdisc_destroy() => ingress_destroy() [b] => tcx_entry_free() => kfree_rcu() // tcx_entry freed 5. Finally, the network namespace is closed. This registers the cleanup_net worker, and during the process of releasing the remaining clsact qdisc, it accesses the tcx_entry that was already freed in step 4, causing the UAF to occur: cleanup_net() => ops_exit_list() => default_device_exit_batch() => unregister_netdevice_many() => unregister_netdevice_many_notify() => dev_shutdown() => qdisc_put() => clsact_destroy() [c] => tcf_block_put_ext() => tcf_chain0_head_change_cb_del() => tcf_chain_head_change_item() => clsact_chain_head_change() => mini_qdisc_pair_swap() // UAF There are also other variants, the gist is to add an ingress (or clsact) qdisc with a specific shared block, then to replace that qdisc, waiting for the tcx_entry kfree_rcu() to be executed and subsequently accessing the current active qdisc's miniq one way or another. The correct fix is to turn the miniq_active boolean into a counter. What can be observed, at step 2 above, the counter transitions from 0->1, at step [a] from 1->2 (in order for the miniq object to remain active during the replacement), then in [b] from 2->1 and finally [c] 1->0 with the eventual release. The reference counter in general ranges from [0,2] and it does not need to be atomic since all access to the counter is protected by the rtnl mutex. With this in place, there is no longer a UAF happening and the tcx_entry is freed at the correct time.
- https://git.kernel.org/stable/c/1cb6f0bae50441f4b4b32a28315853b279c7404e
- https://git.kernel.org/stable/c/1cb6f0bae50441f4b4b32a28315853b279c7404e
- https://git.kernel.org/stable/c/230bb13650b0f186f540500fd5f5f7096a822a2a
- https://git.kernel.org/stable/c/230bb13650b0f186f540500fd5f5f7096a822a2a
- https://git.kernel.org/stable/c/f61ecf1bd5b562ebfd7d430ccb31619857e80857
- https://git.kernel.org/stable/c/f61ecf1bd5b562ebfd7d430ccb31619857e80857
Package alt-csp-cryptopro updated to version 0.3.0-alt3 for branch sisyphus in task 353926.
Closed bugs
Недоступны функции "Создать имя" и "Подписать и сжать" при подписи одного файла