例行回合上游社区补丁

<h3>优先级:</h3>次要<h3>原因分析:</h3>【是否新引入rpm包，是否进行了安全编译选项扫描】不涉及【定位分析】回合社区补丁<table ><tr><td colSpan="1" rowSpan="1">软件包</td><td colSpan="1" rowSpan="1">CommitId</td><td colSpan="1" rowSpan="1">描述</td></tr><tr><td colSpan="1" rowSpan="1">openEuler:rsyslog</td><td colSpan="1" rowSpan="1">3ccbc99a1bf6b2da543c9db9ac03aca2019fc50f</td><td colSpan="1" rowSpan="1">rainerscript: do not try to call a function if it does not exist</td></tr><tr><td colSpan="1" rowSpan="1">openEuler:rsyslog</td><td colSpan="1" rowSpan="1">56deafaa49f039ede3f02428c5e8c56e4493cd55</td><td colSpan="1" rowSpan="1">gnutls bugfix: Add timeout to GnuTLS handshake When forwarding logs to a remote server, it appears that an rsyslogclient with gtls netstream driver will wait forever on TLS handshaketo complete if the server doesn&#x27;t answer. Adding a timeout fixesthe error.</td></tr><tr><td colSpan="1" rowSpan="1">openEuler:rsyslog</td><td colSpan="1" rowSpan="1">d24fd00c935e167a095f4725262ad52546404552</td><td colSpan="1" rowSpan="1">gnutls bugfix: Avoid blocking sockets during TLS handshake When forwarding logs to a TLS server, using a blocking socketcan lead to indefinite waiting during the gnutls_handshake()call if the server does not respond as expected.This commit modifies the behavior to use non-blocking sockets,ensuring that the rsyslog client does not hang indefinitelywaiting for a response.</td></tr><tr><td colSpan="1" rowSpan="1">openEuler:rsyslog</td><td colSpan="1" rowSpan="1">3c00ecb73e72abaa436a06421980cb02de5d0515</td><td colSpan="1" rowSpan="1">core: fix potential NULL ptr access on HUP in very early startup phase found be clang static analyzer, no report from practice. This couldpotentially happend during early startup when the config was notyet full read while HUP was received.</td></tr><tr><td colSpan="1" rowSpan="1">openEuler:rsyslog</td><td colSpan="1" rowSpan="1">ff6f4ceeed8ba715ea0e26d36e2afac2f6c07931</td><td colSpan="1" rowSpan="1">gnutls TLS driver: fix small memory leak found by CoverityScansee also https://github.com/rsyslog/rsyslog/pull/5329</td></tr><tr><td colSpan="1" rowSpan="1">openEuler:rsyslog</td><td colSpan="1" rowSpan="1">6c04651db771fc44f24d3bef499bdf6837633042</td><td colSpan="1" rowSpan="1">rsyslog startup bugfix: cosmetic memory leak This was detected by Coverity Scan, and we fix it to keep Coveritysilent. It is a &lt; 100 byte mem leak that occurs once on startup.</td></tr><tr><td colSpan="1" rowSpan="1">openEuler:rsyslog</td><td colSpan="1" rowSpan="1">6b1b15842c7bb71948c37c362053bd1a1cec98d8</td><td colSpan="1" rowSpan="1">core: fix potential misadressing in sigmask This code is inside rsyslog for many years w/o any problems, butduring new testing we saw that the signal mask is potentially notproperly initialized.</td></tr><tr><td colSpan="1" rowSpan="1">openEuler:rsyslog</td><td colSpan="1" rowSpan="1">0ac9aafb72588ff6c5bc0923fee2dcc7076f4855</td><td colSpan="1" rowSpan="1">omfwd: fix segfault in UDP freeaddrinfo</td></tr><tr><td colSpan="1" rowSpan="1">openEuler:rsyslog</td><td colSpan="1" rowSpan="1">09a3448a3e6ac5aa7065fd56d229a66eacece4db</td><td colSpan="1" rowSpan="1">covscan: remove defect type of RESOURCE_LEAK Fix memory leaks when evaluating variable in rainerscript</td></tr><tr><td colSpan="1" rowSpan="1">openEuler:rsyslog</td><td colSpan="1" rowSpan="1">e06569ecea1b5c0cd1c35699f31ab3929d431d2a</td><td colSpan="1" rowSpan="1">Fix a buffer overflow when the argument to replace is empty We have these expressions in rsyslogd.conf. set $!rsyslog_FileFormat = exec_template(RSYSLOG_FileFormat) set $!localheader = re_extract($!rsyslog_FileFormat, [^ ]+.* +port[0-9], 0, 0, ); set $!localpattern = re_extract($!rsyslog_FileFormat, [^ ]+ +[^ ]+ +port[0-9], 0, 0, ); set $!localheader = replace($!localheader, $!localpattern, ); We have a message like this arriving. &lt;30&gt;Feb 24 22:08:21 hostname port03 &#x27;label&#x27; RXDATA: \n It was observed that when 2 of these messages arrive in a row, rsyslogd crashes. This is clearly due to memory corruption, as the crash comes from within calloc. Unlike the crash, valgrind only complained about the first message. It reported that the &#x27;find&#x27; variable was being accessed in the replace function, reading past allocated data. The localpattern variable ends up empty (null?), because the pattern fails to match. This ends up passed into the replace function as an es_str_t with a length and buffer length of 0. There is no string data, not even a null terminator. As a result, the &#x27;find&#x27; pointer is invalid, and accessing it is an error. Protect against accessing the &#x27;find&#x27; pointer when the buffer is empty by exiting the two loops when j == lfind and lfind == 0. This removes the report from valgrind, and stops rsyslogd from crashing.</td></tr></table>【对外部是否有影响】不涉及
**二、缺陷分析结构反馈**
影响性分析说明：

缺陷严重等级:(Critical/High/Moderate/Low)

缺陷根因说明:

受影响版本排查(受影响/不受影响):
openEuler-20.03-LTS-SP4
openEuler-22.03-LTS-SP3
openEuler-22.03-LTS-SP4
openEuler-24.03-LTS
openEuler-24.03-LTS-SP1
openEuler-24.03-LTS-SP2

修复是否涉及abi变化(是/否):
openEuler-20.03-LTS-SP4
openEuler-22.03-LTS-SP3
openEuler-22.03-LTS-SP4
openEuler-24.03-LTS
openEuler-24.03-LTS-SP1
openEuler-24.03-LTS-SP2

src-openEuler/rsyslog

内容风险标识

评论 (4)

src-openEuler/rsyslog .gitee-modal { width: 500px !important; }

内容风险标识