An oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code.
To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates.
Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup.
In the Linux kernel, the following vulnerability has been resolved:
media: cx231xx: set devicecaps for 417
The videodevice for the MPEG encoder did not set devicecaps.
Add this, otherwise the video device can't be registered (you get a WARNON instead).
Not seen before since currently 417 support is disabled, but I found this while experimenting with it.
Last updated 31 March 2025
Last updated 24 February 2025
Last updated 24 July 2024
Last updated 24 July 2024
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix uninit-value for saddr in dooutputroute4
syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to retsaddr.
[1] BUG: KMSAN: uninit-value in dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 ipvsgetoutrt+0x403/0x21d0 net/netfilter/ipvs/ipvsxmit.c:330 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 syssendmsg+0x28d/0x3c0 net/socket.c:2620 syssendmmsg+0x41d/0x880 net/socket.c:2702 compatsyssendmmsg net/compat.c:360 [inline] docompatsyssendmmsg net/compat.c:367 [inline] secompatsyssendmmsg net/compat.c:364 [inline] ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafterhwframe+0x84/0x8e
Uninit was created at: slabpostallochook mm/slub.c:4167 [inline] slaballocnode mm/slub.c:4210 [inline] kmalloccachenoprof+0x8fa/0xe00 mm/slub.c:4367 kmallocnoprof include/linux/slab.h:905 [inline] ipvsdestdstalloc net/netfilter/ipvs/ipvsxmit.c:61 [inline] ipvsgetoutrt+0x35d/0x21d0 net/netfilter/ipvs/ipvsxmit.c:323 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 syssendmsg+0x28d/0x3c0 net/socket.c:2620 syssendmmsg+0x41d/0x880 net/socket.c:2702 compatsyssendmmsg net/compat.c:360 [inline] docompatsyssendmmsg net/compat.c:367 [inline] secompatsyssendmmsg net/compat.c:364 [inline] ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafterhwframe+0x84/0x8e
CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---
drm/amdgpu: handle amdgpucgscreatedevice() errors in amdpowerplaycreate()
bpf: Fix deadlock between rcutaskstrace and eventmutex.
drm/amdkfd: Destroy KFD debugfs after destroy KFD wq
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise getuser() to probe user read access
Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so getuser() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call.
Fix this by probing read access rights at privilege level 3 (PRIVUSER) and setting guerr to -EFAULT (-14) if access isn't allowed.
Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm.
In the Linux kernel, the following vulnerability has been resolved:
x86/sgx: Prevent attempts to reclaim poisoned pages
TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it knows are poisoned. Avoid even trying to reclaim poisoned pages.
The longer story:
Pages used by an enclave only get epcpage->poison set in archmemoryfailure() but they currently stay on sgxactivepagelist until sgxenclrelease(), with the SGXEPCPAGERECLAIMERTRACKED flag untouched.
epcpage->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic.
Specifically, reclaiming uses microcode operations including "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time.
Call sgxunmarkpagereclaimable() to remove the affected EPC page from sgxactivepagelist on memory error to stop it being considered for reclaiming.
Testing epcpage->poison in sgxreclaimpages() would also work but I assume it's better to add code in the less likely paths.
The affected EPC page is not added to &node->sgxpoisonpagelist until later in sgxenclrelease()->sgxfreeepcpage() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgxactivepagelist. There's a "TBD" comment in archmemoryfailure() about pre-emptive actions, the goal here is not to address everything that it may imply.
This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgxreclaimpages() has selected its candidates or even inside a microcode operation (actually easy to trigger due to the amount of time spent in them.)
The spinlock in sgxunmarkpagereclaimable() is safe because memoryfailure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment.
drm/amdkfd: Don't call mmput from MMU notifier callback
A use-after-free in OpenVPN 2.6.0 through 2.6.20 and 2.7alpha1 through 2.7.4 allows remote authenticated peers to potentially cause a denial of service or leak memory via crafted packets during TLS session promotion or expiry
In the Linux kernel, the following vulnerability has been resolved:
media: venus: protect against spurious interrupts during probe
Make sure the interrupt handler is initialized before the interrupt is registered.
If the IRQ is registered before hficreate(), it's possible that an interrupt fires before the handler setup is complete, leading to a NULL dereference.
This error condition has been observed during system boot on Rb3Gen2.
If a Jetty OpenIdAuthenticator uses the optional nested LoginService, and that LoginService decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated.
So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the LoginService.
Impact This impacts usages of the jetty-openid which have configured a nested LoginService and where that LoginService will is capable of rejecting previously authenticated users.
Original Report working on a custom OpenIdAuthenticator, I discovered the following: https://github.com/eclipse/jetty.project/blob/jetty-10.0.14/jetty-openid/src/main/java/org/eclipse/jetty/security/openid/OpenIdAuthenticator.java#L505 In the case where the LoginService does return that the authentication has been revoked (from the validate() call on line 463), the OpenIdAuthenticator removes the authentication from the session; however the current request still proceeds as if authenticated, since it falls through to "return authentication" on line 505. This is fixed by moving the line 505 (and associated debug log) inside the else block that ends on line 502, instead of outside it. Then the revocation case will run through to line 517 and will trigger a new OpenId authentication which I think is correct. I think this revocation can only occur if you do attach a separate LoginService to the OpenIdLoginService, but in that case the revoked authentication will still let the next request through (and possibly more than one if they are very close to simultaneous). Technically I think this is a security vulnerability, if a very minor one, so I'm sending this off-list.
Patched Versions
Fixed in Jetty Versions: 9.4.52 - fixed in PR https://github.com/eclipse/jetty.project/pull/9660 10.0.16 - fixed in PR https://github.com/eclipse/jetty.project/pull/9528 11.0.16 - fixed in PR https://github.com/eclipse/jetty.project/pull/9528 12.0.0 - not impacted (already has fix)
Workaround Upgrade your version of Jetty.
References https://github.com/eclipse/jetty.project/pull/9528 https://github.com/eclipse/jetty.project/pull/9660
Issue summary: Processing some specially crafted ASN.1 object identifiers or data containing them may be very slow.
Impact summary: Applications that use OBJobj2txt() directly, or use any of the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message size limit may experience notable to very long delays when processing those messages, which may lead to a Denial of Service.
A flaw was found in expat. A stack exhaustion in doctype parsing could be triggered by a file with a large number of opening braces, resulting in a denial of service.
A flaw was found in Apache Commons Net's FTP, where the client trusts the host from PASV response by default. A malicious server could redirect the Commons Net code to use a different host, but the user has to connect to the malicious server in the first place. This issue could lead to leakage of information about services running on the private network of the client.
It was discovered that the XMLEntityManager class implementation in the JAXP component of OpenJDK did not properly perform access checks. A Java application using SAX XML parser in certain configuration could be tricked into disclosing information when parsing a specially-crafted XML file.
A flaw was found in the way the XMLEntityScanner and XML11EntityScanner classes in the JAXP component of OpenJDK handled and normalized newlines in XML entities. A specially-crafted XML document could cause a Java application to enter an infinite loop when parsed.
Impact
Jetty accepts the '+' character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response.
Workarounds
There is no workaround as there is no known exploit scenario.
Original Report
RFC 9110 Secion 8.6 defined the value of Content-Length header should be a string of 0-9 digits. However we found that Jetty accepts "+" prefixed Content-Length, which could lead to potential HTTP request smuggling.
Payload:
POST / HTTP/1.1 Host: a.com Content-Length: +16 Connection: close 0123456789abcdef
When sending this payload to Jetty, it can successfully parse and identify the length.
When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request.
This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS.
Eclipse Jetty Canonical Repository is the canonical repository for the Jetty project. Users of the CgiServlet with a very specific command structure may have the wrong command executed. If a user sends a request to a org.eclipse.jetty.servlets.CGI Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. This issue was patched in version 9.4.52, 10.0.16, 11.0.16 and 12.0.0-beta2.
Incomplete Cleanup vulnerability in Apache Tomcat.
When recycling various internal objects in Apache Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.80 and from 8.5.0 through 8.5.93, an error could cause Tomcat to skip some parts of the recycling process leading to information leaking from the current request/response to the next.
Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fixes the issue.
Improper Input Validation vulnerability in Apache Tomcat.
Tomcat from 11.0.0-M1 through 11.0.0-M11, from 10.1.0-M1 through 10.1.13, from 9.0.0-M1 through 9.0.81 and from 8.5.0 through 8.5.93 did not correctly parse HTTP trailer headers. A specially crafted, invalid trailer header could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.
Users are recommended to upgrade to version 11.0.0-M12 onwards, 10.1.14 onwards, 9.0.81 onwards or 8.5.94 onwards, which fix the issue.
Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with " (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: DISPLAYLANGUAGE="b; JSESSIONID=1337; c=d" will be parsed as one cookie, with the name DISPLAYLANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAYLANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAYLANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.
If the ROOT (default) web application is configured to use FORM authentication then it is possible that a specially crafted URL could be used to trigger a redirect to an URL of the attackers choice.
https://lists.apache.org/thread/71wvwprtx2j2m54fovq9zr7gbm2wow2f https://github.com/advisories/GHSA-q3mw-pvr8-9ggc
A flaw was found in redis. When using the Redis Lua Debugger, users can send malformed requests that cause the debugger’s protocol parser to read data beyond the actual buffer, potentially leading to an information disclosure.
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Use memcpy() for BIOS version
The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in.
Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated.
BIOSVersion is only used for the lpfcprintflog() which expects a properly terminated string.
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during miinwayrestart
In miinwayrestart() the code attempts to call mii->mdioread which is ch9200mdioread(). ch9200mdioread() utilises a local buffer called "buff", which is initialised with controlread(). However "buff" is conditionally initialised inside controlread():
if (err == size) { memcpy(data, buf, size); }
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200mdioread():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200mdioread() ignores the return value of controlread(), leading to uinit-access of "buff".
To fix this we should check the return value of controlread() and return early on error.