Apache 2.4.41 has been released on August 14, fixing several security issues: http://www.apache.org/dist/httpd/CHANGES_2.4.41 https://httpd.apache.org/security/vulnerabilities_24.html Mageia 6 and Mageia 7 are also affected.
Whiteboard: (none) => MGA7TOO, MGA6TOOStatus comment: (none) => Fixed upstream in 2.4.41Blocks: (none) => 24615
Assigning to Shlomi as the Apache registered maintainer. CC'ing neoclust as you are much cited also for Apache packages.
Assignee: bugsquad => shlomifCC: (none) => mageia
Debian has issued an advisory for this on August 26: https://www.debian.org/security/2019/dsa-4509
openSUSE has issued an advisory for this on September 2: https://lists.opensuse.org/opensuse-updates/2019-09/msg00012.html
CC: (none) => shlomifAssignee: shlomif => pkg-bugs
Suggested advisory: ======================== The updated packages fix security vulnerabilities: Some HTTP/2 implementations are vulnerable to unconstrained interal data buffering, potentially leading to a denial of service. The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both. (CVE-2019-9517) HTTP/2 (2.4.20 through 2.4.39) very early pushes, for example configured with "H2PushResource", could lead to an overwrite of memory in the pushing request's pool, leading to crashes. The memory copied is that of the configured push link header values, not data supplied by the client. (CVE-2019-10081) In Apache HTTP Server 2.4.18-2.4.39, using fuzzed network input, the http/2 session handling could be made to read memory after being freed, during connection shutdown. (CVE-2019-10082) In Apache HTTP Server 2.4.0-2.4.39, a limited cross-site scripting issue was reported affecting the mod_proxy error page. An attacker could cause the link on the error page to be malformed and instead point to a page of their choice. This would only be exploitable where a server was set up with proxying enabled but was misconfigured in such a way that the Proxy Error page was displayed. (CVE-2019-10092) In Apache HTTP Server 2.4.32-2.4.39, when mod_remoteip was configured to use a trusted intermediary proxy server using the "PROXY" protocol, a specially crafted PROXY header could trigger a stack buffer overflow or NULL pointer deference. This vulnerability could only be triggered by a trusted proxy and not by untrusted HTTP clients. (CVE-2019-10097) In Apache HTTP server 2.4.0 to 2.4.39, Redirects configured with mod_rewrite that were intended to be self-referential might be fooled by encoded newlines and redirect instead to an unexpected URL within the request URL. (CVE-2019-10098) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9517 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10081 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10082 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10092 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10097 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10098 http://www.apache.org/dist/httpd/CHANGES_2.4.41 https://httpd.apache.org/security/vulnerabilities_24.html https://www.debian.org/security/2019/dsa-4509 https://lists.opensuse.org/opensuse-updates/2019-09/msg00012.html ======================== Updated packages in core/updates_testing: ======================== apache-2.4.41-1.mga7 apache-mod_dav-2.4.41-1.mga7 apache-mod_ldap-2.4.41-1.mga7 apache-mod_session-2.4.41-1.mga7 apache-mod_cache-2.4.41-1.mga7 apache-mod_proxy-2.4.41-1.mga7 apache-mod_proxy_html-2.4.41-1.mga7 apache-mod_suexec-2.4.41-1.mga7 apache-mod_userdir-2.4.41-1.mga7 apache-mod_ssl-2.4.41-1.mga7 apache-mod_dbd-2.4.41-1.mga7 apache-mod_http2-2.4.41-1.mga7 apache-mod_brotli-2.4.41-1.mga7 apache-htcacheclean-2.4.41-1.mga7 apache-devel-2.4.41-1.mga7 apache-doc-2.4.41-1.mga7 from SRPMS: apache-2.4.41-1.mga7.src.rpm
Version: Cauldron => 7Status: NEW => ASSIGNEDWhiteboard: MGA7TOO, MGA6TOO => (none)CC: (none) => nicolas.salgueroAssignee: pkg-bugs => qa-bugs
MGA7-64 Plasma on Lenovo B50 No installation issues. At CLI: # systemctl -l start httpd Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details. # journalctl -xe nov 28 14:06:58 mach5.hviaene.thuis systemd[1]: httpd.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The unit httpd.service has entered the 'failed' state with result 'exit-code'. nov 28 14:06:58 mach5.hviaene.thuis systemd[1]: Failed to start The Apache HTTP Server. -- Subject: A start job for unit httpd.service has failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A start job for unit httpd.service has finished with a failure. -- -- The job identifier is 2834 and the job result is failed. nov 28 14:07:16 mach5.hviaene.thuis kwin_x11[11687]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 61930, resource id: 102760573, major code: 18 (ChangeProperty), minor c> nov 28 14:07:23 mach5.hviaene.thuis kernel: WARNING: CPU: 1 PID: 30492 at fs/ext4/inode.c:3941 ext4_set_page_dirty+0x3e/0x50 nov 28 14:07:23 mach5.hviaene.thuis kernel: Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace sunrpc fscache rfcomm ip6t_REJECT nf_reject_ipv6 xt_comment ip6table_mangle> nov 28 14:07:23 mach5.hviaene.thuis kernel: snd_hda_codec_realtek snd_hda_codec_generic mc ledtrig_audio btusb snd_hda_codec_hdmi btbcm btrtl snd_hda_intel intel_rapl_msr snd_hda_codec in> nov 28 14:07:23 mach5.hviaene.thuis kernel: rtsx_pci_sdmmc mmc_block mmc_core xhci_pci xhci_hcd rtsx_pci ehci_pci ehci_hcd usbcore serio_raw sr_mod ttm usb_common i915 wmi i2c_algo_bit dr> nov 28 14:07:23 mach5.hviaene.thuis kernel: CPU: 1 PID: 30492 Comm: kworker/u8:1 Not tainted 5.3.11-desktop-1.mga7 #1 nov 28 14:07:23 mach5.hviaene.thuis kernel: Hardware name: LENOVO 80EW/Lenovo B50-80, BIOS A8CN47WW(V3.00) 07/14/2015 nov 28 14:07:23 mach5.hviaene.thuis kernel: Workqueue: i915 __i915_gem_free_work [i915] nov 28 14:07:23 mach5.hviaene.thuis kernel: RIP: 0010:ext4_set_page_dirty+0x3e/0x50 nov 28 14:07:23 mach5.hviaene.thuis kernel: Code: 48 8b 00 a8 01 75 16 48 8b 57 08 48 8d 42 ff 83 e2 01 48 0f 44 c7 48 8b 00 a8 08 74 0d 48 8b 07 f6 c4 20 74 0f e9 a2 81 f8 ff <0f> 0b 48 8> nov 28 14:07:23 mach5.hviaene.thuis kernel: RSP: 0018:ffffa6a4860c7dc0 EFLAGS: 00010246 nov 28 14:07:23 mach5.hviaene.thuis kernel: RAX: 0200000000002036 RBX: ffffe990c5656c40 RCX: 0000000000000000 nov 28 14:07:23 mach5.hviaene.thuis kernel: RDX: 0000000000000000 RSI: 000000016f2cd000 RDI: ffffe990c5656c40 nov 28 14:07:23 mach5.hviaene.thuis kernel: RBP: ffff9882e3f4c000 R08: 0000000000000000 R09: ffffffffc04f9600 nov 28 14:07:23 mach5.hviaene.thuis kernel: R10: ffff9882e2820c80 R11: 0000000000000000 R12: 00000000001595b1 nov 28 14:07:23 mach5.hviaene.thuis kernel: R13: ffff9882e440e400 R14: ffff98834c11b930 R15: 0000000000000000 nov 28 14:07:23 mach5.hviaene.thuis kernel: FS: 0000000000000000(0000) GS:ffff988356a80000(0000) knlGS:0000000000000000 nov 28 14:07:23 mach5.hviaene.thuis kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 nov 28 14:07:23 mach5.hviaene.thuis kernel: CR2: 00007fb248c7b180 CR3: 000000008b20a003 CR4: 00000000003606e0 nov 28 14:07:23 mach5.hviaene.thuis kernel: Call Trace: nov 28 14:07:23 mach5.hviaene.thuis kernel: i915_gem_userptr_put_pages+0x13d/0x190 [i915] nov 28 14:07:23 mach5.hviaene.thuis kernel: __i915_gem_object_put_pages+0x63/0x90 [i915] nov 28 14:07:23 mach5.hviaene.thuis kernel: __i915_gem_free_objects+0x11a/0x210 [i915] nov 28 14:07:23 mach5.hviaene.thuis kernel: __i915_gem_free_work+0x53/0x80 [i915] nov 28 14:07:23 mach5.hviaene.thuis kernel: process_one_work+0x200/0x3c0 nov 28 14:07:23 mach5.hviaene.thuis kernel: worker_thread+0x2d/0x3d0 nov 28 14:07:23 mach5.hviaene.thuis kernel: ? process_one_work+0x3c0/0x3c0 nov 28 14:07:23 mach5.hviaene.thuis kernel: kthread+0x112/0x130 nov 28 14:07:23 mach5.hviaene.thuis kernel: ? kthread_create_on_node+0x60/0x60 nov 28 14:07:23 mach5.hviaene.thuis kernel: ret_from_fork+0x35/0x40 nov 28 14:07:23 mach5.hviaene.thuis kernel: ---[ end trace 465ebc2176bfad16 ]---
CC: (none) => herman.viaene
Went thru the same exercise as a few months ago: removed everything apache, deleted /etc/httpd, and installed just apache. That starts OK. Added then the other packages one by one in alphabetical order, each time start apache, check status and stop again. All goes well till installing apache-mod_dbd # systemctl -l start httpd Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.
On Thomas' instigation I tested this again after installing the new kernel 5.3.13-2, but that doesn't make a difference, same failure.
(In reply to Herman Viaene from comment #7) > On Thomas' instigation I tested this again after installing the new kernel > 5.3.13-2, but that doesn't make a difference, same failure. The difference should be that there is no kernel trace in the logs anymore
CC: (none) => tmb
I've fixed up the broken config for mod_session that prevented apache starting. So the rpms are now (currently building): SRPM: apache-2.4.41-1.1.mga7 RPMS: apache-2.4.41-1.1.mga7 apache-mod_dav-2.4.41-1.1.mga7 apache-mod_ldap-2.4.41-1.1.mga7 apache-mod_session-2.4.41-1.1.mga7 apache-mod_cache-2.4.41-1.1.mga7 apache-mod_proxy-2.4.41-1.1.mga7 apache-mod_proxy_html-2.4.41-1.1.mga7 apache-mod_suexec-2.4.41-1.1.mga7 apache-mod_userdir-2.4.41-1.1.mga7 apache-mod_ssl-2.4.41-1.1.mga7 apache-mod_dbd-2.4.41-1.1.mga7 apache-mod_http2-2.4.41-1.1.mga7 apache-mod_brotli-2.4.41-1.1.mga7 apache-htcacheclean-2.4.41-1.1.mga7 apache-devel-2.4.41-1.1.mga7 apache-doc-2.4.41-1.1.mga7
Keywords: (none) => advisory
Actually, mod_dbd had an error too so (now building): SRPM: apache-2.4.41-1.2.mga7 RPMS: apache-2.4.41-1.2.mga7 apache-devel-2.4.41-1.2.mga7 apache-doc-2.4.41-1.2.mga7 apache-htcacheclean-2.4.41-1.2.mga7 apache-mod_brotli-2.4.41-1.2.mga7 apache-mod_cache-2.4.41-1.2.mga7 apache-mod_dav-2.4.41-1.2.mga7 apache-mod_dbd-2.4.41-1.2.mga7 apache-mod_http2-2.4.41-1.2.mga7 apache-mod_ldap-2.4.41-1.2.mga7 apache-mod_proxy-2.4.41-1.2.mga7 apache-mod_proxy_html-2.4.41-1.2.mga7 apache-mod_session-2.4.41-1.2.mga7 apache-mod_ssl-2.4.41-1.2.mga7 apache-mod_suexec-2.4.41-1.2.mga7 apache-mod_userdir-2.4.41-1.2.mga7
Verified the fixes and my apache servers still works
CC: (none) => sysadmin-bugsKeywords: (none) => validated_updateWhiteboard: (none) => MGA7-64-OK
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0407.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED