xfce4-appfinder: Add version 4.10.1 #2

pmenzel · 2016-06-09T14:17:02Z

No description provided.

Logging out from an XFCE session, the app finder terminates with the segmentation fault below. ``` [87035.640468] xfce4-appfinder[1210]: segfault at 31 ip 000000000040c7c0 sp 00007ffd6b3092f0 error 4 in xfce4-appfinder[400000+1d000] ``` Updating from version 4.10.0 to 4.10.1 fixes the problem [1]. > 4.10.1 > ====== > - Use new glib 2.32 api. > - Autotools updates. > - Detatch from icon theme to avoid segfault (bug #9730). > - Protect against possible null pointers (bug #9109). > - Translation updates: Arabic, Bulgarian, Croatian, Indonesian, Dutch > (Flemish), Serbian, Swedish, Turkish, Uyghur [1] https://bugzilla.xfce.org/show_bug.cgi?id=9730

Update to latest available version before investigating further into the heap corruption problem. #1 0x00007f7685167748 in __GI_abort () at abort.c:89 #2 0x00007f76851a967d in __malloc_assert (assertion=assertion@entry=0x7f7685299470 "(unsigned long) (size) >= (unsigned long) (nb)", file=file@entry=0x7f7685295065 "malloc.c", line=line@entry=3692, function=function@entry=0x7f76852953ed <__func__.11515> "_int_malloc") at malloc.c:293 #3 0x00007f76851ac51a in _int_malloc (av=av@entry=0x7f7648000020, bytes=bytes@entry=2049) at malloc.c:3692 #4 0x00007f76851acbe1 in _int_realloc (av=av@entry=0x7f7648000020, oldp=oldp@entry=0x7f76480019a0, oldsize=oldsize@entry=1040, nb=nb@entry=2064) at malloc.c:4283 #5 0x00007f76851add19 in __GI___libc_realloc (oldmem=0x7f76480019b0, bytes=2049) at malloc.c:3026 #6 0x000055a920baef28 in set_tsd_user_vars () #7 0x000055a920b9d2b4 in ?? () #8 0x00007f76863a9191 in start_thread (arg=0x7f767c1de700) at pthread_create.c:309 #9 0x00007f768521930d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Add a patch to disable building and installation of html documentation. Something used by the html build is pulled over the internet and a recent remote change made the build fail. We don't need html docs and we want a more reliable build. Building HTML documentation. INFO: Initializing package repository /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6 INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl INFO: Updating METADATA... INFO: Computing changes... INFO: Cloning cache of Compat from https://github.com/JuliaLang/Compat.jl.git INFO: Cloning cache of DocStringExtensions from https://github.com/JuliaDocs/DocStringExtensions.jl.git INFO: Cloning cache of Documenter from https://github.com/JuliaDocs/Documenter.jl.git INFO: Installing Compat v0.25.2 INFO: Installing DocStringExtensions v0.3.3 INFO: Installing Documenter v0.11.1 INFO: No packages to install, update or remove Documenter: setting up build directory. Documenter: expanding markdown templates. Documenter: building cross-references. Documenter: running document checks. !! Skipped doctesting. > checking footnote links. Documenter: populating indices. Documenter: rendering document. !! Overwriting '/dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/_build/html/en/assets/arrow.svg'. !! Overwriting '/dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/_build/html/en/assets/documenter.js'. !! Overwriting '/dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/_build/html/en/assets/search.js'. !! Overwriting '/dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/_build/html/en/assets/highlightjs/highlight.js'. !! Overwriting '/dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/_build/html/en/assets/highlightjs/default.css'. !! Overwriting '/dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/_build/html/en/assets/documenter.css'. fatal: Not a git repository (or any parent up to mount point /dev/shm) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). ERROR: LoadError: failed process: Process(`git rev-parse --show-toplevel`, ProcessExited(128)) [128] Stacktrace: [1] pipeline_error(::Base.Process) at ./process.jl:682 [2] read(::Cmd, ::Base.DevNullStream) at ./process.jl:629 [3] readstring at ./process.jl:634 [inlined] (repeats 2 times) [4] readchomp at ./io.jl:491 [inlined] [5] (::Documenter.Utilities.##2#3)() at /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6/Documenter/src/Utilities/Utilities.jl:423 [6] cd(::Documenter.Utilities.##2#3, ::String) at ./file.jl:70 [7] url(::String, ::String) at /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6/Documenter/src/Utilities/Utilities.jl:422 [8] render_article(::Documenter.Writers.HTMLWriter.HTMLContext, ::Documenter.Documents.NavNode) at /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6/Documenter/src/Writers/HTMLWriter.jl:403 [9] render_page(::Documenter.Writers.HTMLWriter.HTMLContext, ::Documenter.Documents.NavNode) at /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6/Documenter/src/Writers/HTMLWriter.jl:170 [10] render(::Documenter.Documents.Document) at /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6/Documenter/src/Writers/HTMLWriter.jl:118 [11] dispatch(::Type{Documenter.Writers.FormatSelector}, ::Symbol, ::Documenter.Documents.Document) at /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6/Documenter/src/Selectors.jl:164 [12] render(::Documenter.Documents.Document) at /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6/Documenter/src/Writers/Writers.jl:66 [13] runner(::Type{Documenter.Builder.RenderDocument}, ::Documenter.Documents.Document) at /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6/Documenter/src/Builder.jl:205 [14] dispatch(::Type{Documenter.Builder.DocumentPipeline}, ::Documenter.Documents.Document) at /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6/Documenter/src/Selectors.jl:164 [15] cd(::Documenter.##2#3{Documenter.Documents.Document}, ::String) at ./file.jl:70 [16] #makedocs#1(::Bool, ::Array{Any,1}, ::Function) at /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/deps/v0.6/Documenter/src/Documenter.jl:198 [17] (::Documenter.#kw##makedocs)(::Array{Any,1}, ::Documenter.#makedocs) at ./<missing>:0 [18] include_from_node1(::String) at ./loading.jl:569 [19] include(::String) at ./sysimg.jl:14 [20] process_options(::Base.JLOptions) at ./client.jl:305 [21] _start() at ./client.jl:371 while loading /dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/make.jl, in expression starting on line 118 Makefile:33: recipe for target 'html' failed make[2]: *** [html] Error 1 make[2]: Leaving directory '/dev/shm/bee-root/julia/julia-0.6.0-0/source/doc' Makefile:119: recipe for target 'docs' failed make[1]: *** [docs] Error 2 make[1]: Leaving directory '/dev/shm/bee-root/julia/julia-0.6.0-0/source' Makefile:59: recipe for target '/dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/_build/html/en/index.html' failed make: *** [/dev/shm/bee-root/julia/julia-0.6.0-0/source/doc/_build/html/en/index.html] Error 2

From [1]: > Optional patch: > http://www.linuxfromscratch.org/patches/blfs/7.10/wireshark-2.0.5-lua_5_3_1-1.patch > (allows building the LUA bindings if Lua-5.3.3 is installed and LUA is > not disabled by passing --without-lua to configure) Applies with a little offset. ``` [BEE] patch -N -p1 -i /dev/shm/bee-root/wireshark/files/wireshark-2.0.5-lua_5_3_1-1.patch patching file configure Hunk #1 succeeded at 38870 (offset 1275 lines). Hunk #2 succeeded at 38974 (offset 1275 lines). Hunk #3 succeeded at 38998 (offset 1275 lines). Hunk #4 succeeded at 39022 (offset 1275 lines). patching file epan/wslua/lua_bitop.c patching file epan/wslua/wslua_byte_array.c patching file epan/wslua/wslua_file.c Hunk #1 succeeded at 347 (offset 10 lines). patching file epan/wslua/wslua.h patching file epan/wslua/wslua_int64.c patching file epan/wslua/wslua_internals.c patching file epan/wslua/wslua_listener.c patching file epan/wslua/wslua_nstime.c patching file epan/wslua/wslua_struct.c patching file epan/wslua/wslua_tvb.c Hunk #3 succeeded at 223 (offset -1 lines). Hunk #4 succeeded at 241 (offset -1 lines). Hunk #5 succeeded at 836 (offset -1 lines). Hunk #6 succeeded at 917 (offset -1 lines). Hunk #7 succeeded at 961 (offset -1 lines). Hunk #8 succeeded at 1008 (offset -1 lines). Hunk #9 succeeded at 1108 (offset -1 lines). ``` With this patch, `Use Lua library : yes` is seen in the configure option summary. [1] http://www.linuxfromscratch.org/blfs/view/7.10/basicnet/wireshark.html

Rust 1.25.0 requires clang 6.0.0. [Release notes for LLVM 6.0.0][1] (excerpt): > ### Non-comprehensive list of changes in this release ### > > * Support for retpolines was added to help mitigate “branch target > injection” (variant #2) of the “Spectre” speculative side channels > described by Project Zero and the Spectre paper. > * The Redirects argument of llvm::sys::ExecuteAndWait and > llvm::sys::ExecuteNoWait was changed to an ArrayRef of optional > StringRef‘s to make it safer and more convenient to use. > * The backend name was added to the Target Registry to allow > run-time information to be fed back into TableGen. Out-of-tree targets > will need to add the name used in the def X : Target definition to the > call to RegisterTarget. > * The Debugify pass was added to opt to facilitate testing of debug > info preservation. This pass attaches synthetic DILocations and > DIVariables to the instructions in a Module. The CheckDebugify pass > determines how much of the metadata is lost. > * Significantly improved quality of CodeView debug info for Windows. > * Preliminary support for Sanitizers and sibling features on > X86(_64) NetBSD (ASan, UBsan, TSan, MSan, SafeStack, libFuzzer). [1]: https://releases.llvm.org/6.0.0/docs/ReleaseNotes.html

[Release notes for 6.0.0][1] (excerpt): > ### Non-comprehensive list of changes in this release ### > > * Support for retpolines was added to help mitigate “branch target injection” > (variant #2) of the “Spectre” speculative side channels described by Project > Zero and the Spectre paper. > * Bitrig OS was merged back into OpenBSD, so Bitrig support has been removed > from Clang/LLVM. > * The default value of _MSC_VER was raised from 1800 to 1911, making it > compatible with the Visual Studio 2015 and 2017 C++ standard library headers. > Users should generally expect this to be regularly raised to match the most > recently released version of the Visual C++ compiler. > * clang now defaults to .init_array if no gcc installation can be found. If a > gcc installation is found, it still prefers .ctors if the found gcc is older > than 4.7.0. > * The new builtin preprocessor macros __is_target_arch, __is_target_vendor, > __is_target_os, and __is_target_environment can be used to to examine the > individual components of the target triple. [1]: https://releases.llvm.org/6.0.0/tools/clang/docs/ReleaseNotes.html

This fixes *Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service issues* [1]. > Netflix has identified several TCP networking vulnerabilities in FreeBSD > and Linux kernels. > > The vulnerabilities specifically relate to the minimum segment size (MSS) > and TCP Selective Acknowledgement (SACK) capabilities. The most serious, > dubbed “SACK Panic,” allows a remotely-triggered kernel panic on recent > Linux kernels. > > There are patches that address most of these vulnerabilities. If patches > can not be applied, certain mitigations will be effective. We recommend > that affected parties enact one of those described below, based on their > environment. > > #1: CVE-2019-11477: SACK Panic (Linux >= 2.6.29) > > Description: A sequence of SACKs may be crafted such that one can trigger > an integer overflow, leading to a kernel panic. > > Fix: Apply the attached patch (“PATCH_net_1_4.patch”). Additionally, > versions of the Linux kernel up to, and including, 4.14 require a second > patch (“PATCH_net_1a.patch”). > > Workaround #1: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to > 0). > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #2: CVE-2019-11478: SACK Slowness (Linux < 4.15) or Excess Resource Usage > (all Linux versions) > > Description: It is possible to send a crafted sequence of SACKs which will > fragment the TCP retransmission queue. On Linux kernels prior to 4.15, an > attacker may be able to further exploit the fragmented queue to cause an > expensive linked-list walk for subsequent SACKs received for that same TCP > connection. > > Fix: Apply the attached patch (“PATCH_net_2_4.patch”) > > Workaround #1: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to > 0). > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #3: CVE-2019-5599: SACK Slowness (FreeBSD 12 using the RACK TCP Stack) > > Description: It is possible to send a crafted sequence of SACKs which will > fragment the RACK send map. An attacker may be able to further exploit the > fragmented send map to cause an expensive linked-list walk for subsequent > SACKs received for that same TCP connection. > > Workaround #1: Apply the attached patch (“split_limit.patch”) and set the > net.inet.tcp.rack.split_limit sysctl to a reasonable value to limit the > size of the SACK table. > > Workaround #2: Temporarily disable the RACK TCP stack. > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #4: CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values (all > Linux versions) > > Description: An attacker can force the Linux kernel to segment its > responses into multiple TCP segments, each of which contains only 8 bytes > of data. This drastically increases the bandwidth required to deliver the > same amount of data. Further, it consumes additional resources (CPU and NIC > processing power). This attack requires continued effort from the attacker > and the impacts will end shortly after the attacker stops sending traffic. > > Fix: Two attached patches (“PATCH_net_3_4.patch” and “PATCH_net_4_4.patch”) > add a sysctl which enforces a minimum MSS, set by the > net.ipv4.tcp_min_snd_mss sysctl. This lets an administrator enforce a > minimum MSS appropriate for their applications. > > Workaround: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > > Note: Good system and application coding and configuration practices > (limiting write buffers to the necessary level, monitoring connection > memory consumption via SO_MEMINFO, and aggressively closing misbehaving > connections) can help to limit the impact of attacks against these kinds of > vulnerabilities. > > An advisory has been published > at https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md > > Acknowledgments: > Originally reported by Jonathan Looney. > We thank Eric Dumazet for providing Linux fixes and support. > We thank Bruce Curtis for providing the Linux filters. > We thank Jonathan Lemon and Alexey Kodanev for helping to improve the Linux > patches. > We gratefully acknowledge the assistance of Tyler Hicks in testing fixes, > refining the information about vulnerable versions, and providing > assistance during the disclosure process. > > Regards, > Netflix Information Security [1]: https://www.openwall.com/lists/oss-security/2019/06/17/5

This fixes *Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service issues* [1]. > Netflix has identified several TCP networking vulnerabilities in FreeBSD > and Linux kernels. > > The vulnerabilities specifically relate to the minimum segment size (MSS) > and TCP Selective Acknowledgement (SACK) capabilities. The most serious, > dubbed “SACK Panic,” allows a remotely-triggered kernel panic on recent > Linux kernels. > > There are patches that address most of these vulnerabilities. If patches > can not be applied, certain mitigations will be effective. We recommend > that affected parties enact one of those described below, based on their > environment. > > #1: CVE-2019-11477: SACK Panic (Linux >= 2.6.29) > > Description: A sequence of SACKs may be crafted such that one can trigger > an integer overflow, leading to a kernel panic. > > Fix: Apply the attached patch (“PATCH_net_1_4.patch”). Additionally, > versions of the Linux kernel up to, and including, 4.14 require a second > patch (“PATCH_net_1a.patch”). > > Workaround #1: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to > 0). > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #2: CVE-2019-11478: SACK Slowness (Linux < 4.15) or Excess Resource Usage > (all Linux versions) > > Description: It is possible to send a crafted sequence of SACKs which will > fragment the TCP retransmission queue. On Linux kernels prior to 4.15, an > attacker may be able to further exploit the fragmented queue to cause an > expensive linked-list walk for subsequent SACKs received for that same TCP > connection. > > Fix: Apply the attached patch (“PATCH_net_2_4.patch”) > > Workaround #1: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to > 0). > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #3: CVE-2019-5599: SACK Slowness (FreeBSD 12 using the RACK TCP Stack) > > Description: It is possible to send a crafted sequence of SACKs which will > fragment the RACK send map. An attacker may be able to further exploit the > fragmented send map to cause an expensive linked-list walk for subsequent > SACKs received for that same TCP connection. > > Workaround #1: Apply the attached patch (“split_limit.patch”) and set the > net.inet.tcp.rack.split_limit sysctl to a reasonable value to limit the > size of the SACK table. > > Workaround #2: Temporarily disable the RACK TCP stack. > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #4: CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values (all > Linux versions) > > Description: An attacker can force the Linux kernel to segment its > responses into multiple TCP segments, each of which contains only 8 bytes > of data. This drastically increases the bandwidth required to deliver the > same amount of data. Further, it consumes additional resources (CPU and NIC > processing power). This attack requires continued effort from the attacker > and the impacts will end shortly after the attacker stops sending traffic. > > Fix: Two attached patches (“PATCH_net_3_4.patch” and “PATCH_net_4_4.patch”) > add a sysctl which enforces a minimum MSS, set by the > net.ipv4.tcp_min_snd_mss sysctl. This lets an administrator enforce a > minimum MSS appropriate for their applications. > > Workaround: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > > Note: Good system and application coding and configuration practices > (limiting write buffers to the necessary level, monitoring connection > memory consumption via SO_MEMINFO, and aggressively closing misbehaving > connections) can help to limit the impact of attacks against these kinds of > vulnerabilities. > > An advisory has been published > at https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md > > Acknowledgments: > Originally reported by Jonathan Looney. > We thank Eric Dumazet for providing Linux fixes and support. > We thank Bruce Curtis for providing the Linux filters. > We thank Jonathan Lemon and Alexey Kodanev for helping to improve the Linux > patches. > We gratefully acknowledge the assistance of Tyler Hicks in testing fixes, > refining the information about vulnerable versions, and providing > assistance during the disclosure process. > > Regards, > Netflix Information Security The other commits between 4.19.40 and 4.19.52 can be found in the [git repository][2]. [1]: https://www.openwall.com/lists/oss-security/2019/06/17/5 [2]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-4.19.y

pmenzel assigned wwwutz Jun 9, 2016

wwwutz merged commit d2f637c into master Jun 9, 2016

donald deleted the add-xfce4-appfinder-1.10.1 branch July 6, 2016 09:48

xfce4-appfinder: Add version 4.10.1 #2

xfce4-appfinder: Add version 4.10.1 #2

Conversation

pmenzel commented Jun 9, 2016