Search: res.in

The Object Transfer Service server builds its Object Action Control Point (OACP) response indication in oacp_ind_send() (subsys/bluetooth/services/ots/ots_oacp.c). Before this fix the four-byte Checksum Value field was appended whenever the requested op code was BT_GATT_OTS_OACP_PROC_CHECKSUM_CALC, regardless of the result code. The response payload is a bare, uninitialized four-byte stack buffer declared with NET_BUF_SIMPLE_DEFINE(resp_param, sizeof(uint32_t)) in bt_gatt_ots_oacp_write(), and it is filled only on the success path of oacp_checksum_proc_validate(). On every failure path the buffer is still empty, so net_buf_simple_pull_le32() was invoked on a zero-length buffer. The OACP characteristic and its client characteristic configuration descriptor are declared with BT_GATT_PERM_WRITE and BT_GATT_PERM_READ | BT_GATT_PERM_WRITE, so no pairing, encryption, or authentication is required. Any peer within radio range that can connect to a device running the OTS server can enable OACP indications and write a nine-byte Calculate Checksum command that fails validation — for example by issuing it with no object selected, which returns BT_GATT_OTS_OACP_RES_INV_OBJ. Because oacp_command_decode() accepts the Calculate Checksum op code unconditionally (it is not guarded by CONFIG_BT_OTS_OACP_CHECKSUM_SUPPORT), builds without checksum support are reachable too: they answer BT_GATT_OTS_OACP_RES_OPCODE_NOT_SUP and take the same bad path. On builds with CONFIG_ASSERT enabled, the zero-length pull trips the assertion inside net_buf_simple_pull_mem() and panics the device, giving a remotely triggered denial of service. On builds with assertions disabled there is no check: the pull returns the untouched stack array and four bytes of uninitialized stack memory are copied into the indication and transmitted to the peer, repeatable on every request. The disclosure is bounded to four bytes per request and the write stays inside the seven-byte res indication buffer, so there is no memory corruption; the impact is uninitialized-memory disclosure plus an availability loss in assertion-enabled configurations.

This entry references issues related to AWS Research and Engineering Studio (RES) but provides no specific details about the nature of the issues, vulnerabilities, or exploits.

CVE-2026-110735 is a low-severity vulnerability in Godot Engine up to version 4.7.2 involving a heap out-of-bounds write in the binary resource loader. The issue arises from a signed to unsigned conversion error when reading a string length from a resource file, which can lead to copying data beyond the allocated buffer. The vulnerability requires loading a crafted binary resource file (.res) and involves attacker access outside the current threat model defined by the vendor.

## Summary Nginx-UI v2.4.3 stores the API JWT in a browser cookie named `token` and the `AuthRequired` middleware accepts that cookie as an authentication source. Because management endpoints are protected by `AuthRequired` and do not enforce a universal CSRF token or Origin/Referer check, a remote attacker can induce a logged-in administrator to submit cross-site state-changing requests. The attacker does not need to read the cross-origin response; the browser-sent cookie is enough to authenticate the request. ## Details The root cause is a trust-boundary failure between browser-managed cookies and API bearer-token authentication. In `app/src/pinia/moudule/user.ts:25-35`, the front end writes the JWT to a `token` cookie when the token changes. In `internal/middleware/middleware.go:16-36`, `getToken` first checks the `Authorization` header and `token` query parameter, then falls back to `c.Cookie("token")`. That fallback causes browser-initiated cross-site requests to carry a valid API credential automatically. The route group in `router/routers.go:87-110` applies `middleware.AuthRequired()` to many management modules, including `config.InitRouter`, `nginx.InitRouter`, `settings.InitRouter`, and backup-related handlers. For accounts without OTP/Passkey, `RequireSecureSession` does not provide a universal second factor for all state-changing operations. A representative sink is `api/config/add.go:68-78`, where an authenticated request writes Nginx configuration with `os.WriteFile` and then calls `nginx.Control(nginx.Reload)`. CORS does not mitigate this issue because preventing cross-origin response reads does not prevent cross-site form or no-cors requests from being sent with cookies. Core vulnerable code path: ```typescript // app/src/pinia/moudule/user.ts:25-35 watch(token, v => { if (v) { cookies.set('token', v, getCookieOptions(86400)) if (!shortToken.value) { void fetchShortToken() } } else { cookies.remove('token', { path: '/' }) shortToken.value = '' } }) ``` The front end stores the authentication token in a `token` cookie. The cookie is created client-side and is not shown here as HttpOnly; it becomes the credential that the back end later accepts through cookie fallback. ```go // internal/middleware/middleware.go:16-36 // getToken from header, cookie or query func getToken(c *gin.Context) (token string) { if token = c.GetHeader("Authorization"); token != "" { return } if token = c.Query("token"); token != "" { if len(token) > 16 { // Long token (base64 encoded JWT) tokenBytes, _ := base64.StdEncoding.DecodeString(token) return string(tokenBytes) } // Short token (16 characters) return token } if token, _ = c.Cookie("token"); token != "" { return token } return "" } ``` `getToken` accepts the `token` cookie as an authentication credential after checking the header and query parameter. That behavior lets a browser-sent cookie authenticate state-changing API requests triggered from another origin. ```go // router/routers.go:87-110 // Authorization required and not websocket request g := root.Group("/", middleware.AuthRequired(), middleware.Proxy()) { debug.InitRouter(g) user.InitUserRouter(g) analytic.InitRouter(g) user.InitManageUserRouter(g) nginx.InitRouter(g) sites.InitRouter(g) streams.InitRouter(g) config.InitRouter(g) template.InitRouter(g) certificate.InitCertificateRouter(g) certificate.InitDNSCredentialRouter(g) certificate.InitAcmeUserRouter(g) dnsapi.InitRouter(g) system.InitPrivateRouter(g) settings.InitRouter(g) llm.InitRouter(g) cluster.InitRouter(g) notification.InitRouter(g) external_notify.InitRouter(g) backup.InitAutoBackupRouter(g) nginxLog.InitRouter(g) upstream.InitHTTPRouter(g) ``` Many management modules, including Nginx, configuration, settings, backup, and user management, are placed behind `AuthRequired`. The cookie fallback therefore protects high-impact state-changing routes, not only read-only endpoints. ```go // api/config/add.go:68-78 err = os.WriteFile(path, []byte(content), 0644) if err != nil { cosy.ErrHandler(c, err) return } res := nginx.Control(nginx.Reload) if res.IsError() { res.RespError(c) return } ``` This representative sink shows why the CSRF is high impact: once authenticated through the cookie fallback, a request can write Nginx configuration content and trigger a reload. ## POC Prerequisites: an administrator is logged in to Nginx-UI and has a browser `token` cookie; the administrator account has not enabled OTP/Passkey, or the chosen target endpoint does not require secure-session proof; the attacker knows the Nginx-UI management URL and can induce the administrator to visit an attacker-controlled page. Reproduction: (1) Host an attacker page at `GET /csrf.html` that automatically submits a cross-site request to the victim instance. (2) The page submits `POST /api/configs`

## Root Cause File: `internal/auditlog/formats.go` — multiple sites write attacker-influenced bytes into the Native audit-log stream without escaping `\r` or `\n`: ```go // Part B — request headers (lines 72–80) for k, vv := range al.Transaction().Request().Headers() { for _, v := range vv { res.WriteByte('\n') res.WriteString(k) res.WriteString(": ") res.WriteString(v) // ← raw } } // Part C — request body (lines 85–86) if body := al.Transaction().Request().Body(); body != "" { res.WriteString(body) // ← raw res.WriteByte('\n') } // Part E — response body (lines 93–94) raw // Part F — response headers (lines 111–118) raw // Part H — error messages (line 125) raw // Part K — matched-rule raw data (line 151) raw ``` The Native format's section structure is line-based: sections are delimited by lines of the form `--<10-char-random-prefix>-<Part>--`, and line-based log parsers / SIEM rules rely on that structure. Any attacker-controlled bytes containing `\n` break the structural invariant and allow the attacker to inject lines that look like genuine audit content. The other two Native-format implementations in Coraza are not affected: the JSON formatter (`formats_json.go`) and the OCSF formatter both round-trip values through `json.Marshal`, which escapes `\r` and `\n`. ## Impact An attacker who can land bytes into any of the listed audit-log fields can inject arbitrary lines — including lines that visually resemble new log entries — into the audit log file of a defender running the default `SecAuditLogFormat Native` configuration. Realistic consequences: - **Forging entries to shift attribution.** An injected line such as `[client "9.9.9.9"] Coraza: Warning. ...` sits alongside genuine matches in Part H, and a human operator (or simple SIEM rule) reading the log cannot tell them apart. - **Confusing SIEM correlation.** Any ingestion pipeline that splits on `--...-[A-Z]--` boundaries or on `[client "..."]` patterns without validating the session prefix will treat the forged lines as separate records. - **Breaking log-parsing tooling.** Grep/awk pipelines, log tailers, and log-rotation tools with line-based assumptions can be poisoned with crafted binary sequences. - **Hiding genuine incidents.** An attacker who can also trigger a rule match on the same transaction (trivial — send any request that matches *any* audit-logged rule) can bury the real match under noise they control. The forged lines cannot trivially impersonate an entire *separate* session: the 10-char random prefix in the real boundaries (`boundaryPrefix := "--" + utils.RandomString(10) + "-"`, line 42) is not predictable from outside, and each transaction uses a fresh prefix. But the integrity of a *single* record is fully compromised, which is enough for the SIEM-confusion and attribution-shifting attacks. ## Proof of Concept Server with `coraza.conf-recommended`-style defaults: ```conf SecRuleEngine On SecAuditEngine On SecAuditLogParts ABCFHZ SecAuditLogType Serial SecAuditLog /tmp/audit.log SecAuditLogFormat Native SecRequestBodyAccess On SecRule REQUEST_METHOD "@rx ." \ "id:1001,phase:1,pass,log,auditlog,msg:'trigger'" ``` ### Body vector — reachable via stock `coraza/v3/http` + `net/http` Send an ordinary urlencoded POST whose body contains raw CRLF sequences and forged boundaries: ``` POST / HTTP/1.1 Content-Type: application/x-www-form-urlencoded evil=benign\r\n--coraza-forged-X--\r\nForgedLine: yes\r\n--coraza-forged-H--\r\n[client "9.9.9.9"] FAKE ATTACK ENTRY ``` Resulting audit.log: ``` --heLNtylvjY-C-- evil=benign --coraza-forged-X-- ForgedLine: yes --coraza-forged-H-- [client "9.9.9.9"] FAKE ATTACK ENTRY --heLNtylvjY-F-- ``` The forged `--coraza-forged-X--` / `--coraza-forged-H--` boundaries and the spoofed `[client "9.9.9.9"]` line are structurally indistinguishable from the surrounding genuine log content. No rule fires, no error is raised, the attack is invisible to the WAF. ### Header vector — reachable via non-net/http integrations only The same effect applies to Part B (request headers) and Part F (response headers) when a header value contains raw `\r\n`. Go's `net/http` rejects such headers at parse time (`400 Bad Request`), so the stock HTTP wrapper is safe from this path; the vector is reachable when Coraza is called with header values that were not validated by `net/http`: - `coraza-spoa` (HAProxy SPOP agent) forwards headers from HAProxy, which has more permissive validation. - `coraza-proxy-wasm` / Envoy WASM hosts forward header values from the upstream proxy. - Custom FFI/WASM hosts and any embedder calling `tx.AddRequestHeader(k, v)` with unvalidated bytes. Other raw-write sites (Part E response body, Part H error messages, Part K matched-rule data) share the same class of issue and should be fixed together. ## Mitigation Escape `\r` and `\n` at every raw-write site in `internal/auditlog/formats.go`. A single package-level

CloudTAK is a browser-based Common Operating Picture and situational awareness tool compatible with TAK. Prior to version 13.10.0, every route in the ESRI helper family (api/routes/esri.ts) takes a fully attacker-controlled URL from the request (POST /api/esri body url, and the portal / server / layer query parameters on the GET /api/esri/* routes) and passes it into EsriBase / EsriProxyPortal / EsriProxyServer / EsriProxyLayer in api/lib/esri.ts, which fetch it with the bare fetch from @tak-ps/etl. No IP / DNS / hostname classification is applied at any point, so the destination is never validated against private, loopback, or link-local ranges. Any authenticated user (the routes only require Auth.is_auth(config, req, { anyResources: true }), i.e. any token, not an admin) can therefore make the CloudTAK server issue arbitrary outbound GET/POST requests to internal addresses such as the cloud instance-metadata service (169.254.169.254), loopback admin ports (127.0.0.1:<port>), and other hosts reachable only from inside the deployment VPC. This is a full-read SSRF, not blind: on success the upstream JSON body is returned to the caller via res.json(...), and on failure the upstream error string is reflected verbatim as ESRI Server Error: <message>. An attacker can read cloud metadata (and the temporary IAM credentials the instance role exposes), enumerate internal services, and exfiltrate their response bodies. The sniff() URL classifier provides no protection: it only pattern-matches the pathname (/rest, /arcgis/rest, /sharing/rest), so a URL like http://169.254.169.254/arcgis/rest or http://127.0.0.1:8500/rest passes sniff() and is fetched. This issue has been patched in version 13.10.0.

Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.4.0, `POST /api/auth/token` authenticates with username and password only, then calls `getTokens()`, which returns full access and refresh JWTs without checking whether the account has TOTP 2FA enabled. An attacker with stolen or phished credentials can bypass 2FA in a single request. The parallel login endpoint (`POST /api/auth/login`) correctly enforces 2FA by calling `setCookies(user, res, true)`, which gates on `user.twoFaEnabled`. Version 2.4.0 patches the issue.

TS3 Manager is modern web interface for maintaining Teamspeak3 servers. Prior to 2.2.6, the /api/download handler in packages/server/routes/api.js passes the attacker-controlled port query parameter to socket.connect(port, host) and returns the resulting error.message through res.status(400).send(error.message) as text/html without a Content Security Policy. When a logged-in operator follows a crafted top-level link, the reflected value executes in the manager origin. The token cookie set in packages/ui/src/store/modules/query.js lacks HttpOnly, Secure, and an explicit SameSite attribute, allowing the script to read the token and call the autofillform event in packages/server/socket.js. autofillform returns the decoded JWT, including the cleartext ServerQuery password, enabling operator-session hijacking and control of the managed TeamSpeak server when the operator uses administrative ServerQuery credentials. A valid operator session and user interaction are required. This issue is fixed in 2.2.6.

## Summary Mockoon's admin API ([`commons-server/src/libs/server/admin-api.ts`](https://github.com/mockoon/mockoon/blob/4375a8f/packages/commons-server/src/libs/server/admin-api.ts)) is mounted on the same Express listener as the user-defined mock routes, **enabled by default** in every shipped runtime (commons-server, CLI, serverless), serves **`Access-Control-Allow-Origin: *` on every endpoint with all HTTP methods allowed including PUT/POST/PATCH/DELETE/PURGE and `Content-Type` in `Access-Control-Allow-Headers`**, and has **zero authentication of any kind** (no token, no shared secret, no `MOCKOON_ADMIN_TOKEN` env var — searched the repo, returns zero hits). Any unauthenticated caller who can reach the mock server's port (default `0.0.0.0:3000`) can: - Read every `MOCKOON_*` env var used by the operator as secret material in templates (`getEnvVar` helper). - **Write arbitrary process env vars (no prefix check on the WRITE path)** — poison operator's `MOCKOON_API_KEY`, `MOCKOON_JWT_SECRET`, …, or write process-level vars like `AWS_SECRET_ACCESS_KEY` that the surrounding runtime consumes. - **Rewrite every mock route's body / status / headers in-runtime** via `PUT /mockoon-admin/environment` — downstream consumers (frontend dev-server, CI test suite, integration partner) receive attacker-controlled responses and headers including `Set-Cookie`, `Location`, `Content-Security-Policy`, etc. - Read transaction logs / SSE stream (consumer's request bodies + auth headers in clear). - Read/write global template vars; purge state / data buckets / logs. Because of the wildcard CORS reply, the attack **also lands cross-origin from a browser**: a developer who runs `mockoon-cli start ...` locally and visits a malicious website gets their mock state hijacked. --- ## Details ### Root cause `packages/commons-server/src/libs/server/server.ts:127`: ```ts private options: ServerOptions = { ..., enableAdminApi: true, // ← default on }; ``` `packages/cli/src/commands/start.ts:200`: ```ts enableAdminApi: !userFlags['disable-admin-api'], // default true unless --disable-admin-api passed ``` `packages/serverless/src/libs/serverless.ts:21`: ```ts enableAdminApi: true, // ← default on, no flag to disable in the constructor ``` `packages/commons-server/src/libs/server/admin-api.ts:63-74` (permissive CORS on every admin endpoint): ```ts app.use(`${adminApiPrefix}*`, (req, res, next) => { res.setHeaders( new Headers({ 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Methods': 'GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS', 'Access-Control-Allow-Headers': 'Content-Type, Origin, Accept, Authorization, Content-Length, X-Requested-With' }) ); next(); }); ``` `packages/commons-server/src/libs/server/admin-api.ts:151-166` (no auth, no prefix check on WRITE): ```ts const setEnvVarHandler = (req, res) => { try { const { key, value } = req.body; if (key !== undefined && value !== undefined) { process.env[key] = value; // ← any process env, any value res.send({ message: `Environment variable '${key}' has been set to '${value}'` }); } else { throw new Error('Key or value missing from request'); } } catch (_error) { res.status(400).send({ message: 'Invalid request' }); } }; ``` `packages/commons-server/src/libs/server/admin-api.ts:373-393` (the most impactful — runtime mock rewrite): ```ts app.put(`${adminApiPrefix}/environment`, (req, res) => { try { const environment: Environment = EnvironmentSchema.validate(req.body).value; if (!environment) { res.status(400).send({ message: 'Invalid environment format' }); return; } updateEnvironment(environment); // ← runtime mutation of every route response res.send({ message: 'Environment updated' }); } catch (_error) { res.status(400).send({ message: 'Invalid environment format' }); } }); ``` Default `hostname: ''` (`packages/commons/src/constants/environment-schema.constants.ts:33`) → Node binds `0.0.0.0`/`::` (confirmed via `lsof`). Migration #16 (`packages/commons/src/libs/migrations.ts:343`) also forces missing hostnames to `'0.0.0.0'`. --- ## PoC ### Live reproduction (2026-05-11, `@mockoon/cli@9.6.1`) `npm install @mockoon/cli@9.6.1`. Minimal `env.json` with one route `GET /users/:id` whose response templates `{{getEnvVar 'MOCKOON_API_KEY'}}`. Start with: ``` MOCKOON_API_KEY="sk-operator-real-secret-DO_NOT_LEAK_xyz789" \ mockoon-cli start --data env.json --port 3100 --repair --disable-log-to-file ``` Bind confirmed via `lsof`: ``` COMMAND PID USER FD TYPE ... NAME node 39906 ... 14u IPv6 ... TCP *:3100 (LISTEN) <-- all interfaces ``` Baseline mock response: ``` $ curl -s http://127.0.0.1:3100/users/42 {"id":"42","name":"BENIGN_ALICE","role":"user","apiKey":"sk-operator-real-secret-DO_NOT_LEAK_xyz789"} ``` #### 1) Read operator secret unauth

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: use check_add_overflow for shader size+offset bound vmw_shader_define() validates the user-supplied shader window against its backing buffer with (u64)buffer->tbo.base.size < (u64)size + (u64)offset drm_vmw_shader_create_arg::offset is __u64 in the uapi; when it is near U64_MAX the unsigned addition wraps and the resulting tiny value passes the check. The unbounded offset is then stored in res->guest_memory_offset and forwarded to host SVGA shader-create commands. Use check_add_overflow() to detect the wrap and compare the resulting endpoint against the buffer size.

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp rxe_qp_from_attr() handles IB_QP_MAX_DEST_RD_ATOMIC outside the IB_QP_STATE path, so it holds no state_lock and runs while the responder task rxe_receiver() (recv_task on rxe_wq) is live. A modify_qp() setting only that attribute calls free_rd_atomic_resources() then alloc_rd_atomic_resources(), swapping qp->resp.resources[] while rxe_prepare_res()/find_resource() walk it; free_rd_atomic_resources() also leaves the cached pointer qp->resp.res dangling. A local unprivileged user can race the free/realloc into a use-after-free in rxe_receiver() (local DoS). Drain recv_task around the swap with rxe_disable_task()/rxe_enable_task(), as rxe_qp_reset() already does when tearing this array down, re-enabling only after alloc_rd_atomic_resources() succeeds so the responder never resumes against a NULL qp->resp.resources on the ENOMEM path. Also clear qp->resp.res in free_rd_atomic_resources(), like the rxe_resp.c completion paths. Reproduced under KASAN; the slab-use-after-free in rxe_receiver() is gone.

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: fanotify: fix false positive on permission events (CVE-2026-46150) * kernel: ip6_gre: Use cached t->net in ip6erspan_changelink() (CVE-2026-46120) * kernel: af_unix: Set gc_in_progress to true in unix_gc() (CVE-2026-53361) * kernel: ipv4: free net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table() (CVE-2026-64002) * kernel: net: bridge: stop fast-leave after deleting a port group (CVE-2026-74480) * kernel: packet: use consistent hard_header_len in non-ring send paths () * kernel: net: ipv6: use-after-free in fib6_rule_suppress due to stale res->rt6 pointer (CVE-2026-74581) Bug Fix(es) and Enhancement(s): * [kABI] protect struct alt_instr [rhel-10.0] (JIRA:RHEL-122758) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

This update for broot fixes the following issues: Changes in broot: - v1.59.0 (CVE-2026-72847 boo#1275994) * new shell_command verb attribute: run a command through a shell (sh -c / cmd /C) so &&, ; and pipes work, without leaving broot - Fix #1145 * fix invalid official Mac binary (duplicate linked dylib) with new build chain - Fix #1194 * Sixel graphics support for image preview, auto-detected: works in iterm2, Windows Terminal 1.22+ and Sixel-capable Unix terminals (foot, mlterm, xterm built with Sixel, recent WezTerm). Kitty remains the preferred protocol when available. Note: this requires broot to be compiled with sixel feature (eg cargo install broot --features sixel) - Fix #568 * High-Res images in Rio terminal (detect it to enable the Kitty image protocol) - Fix #1179 * fix iTerm2 3.6.10 and later not displaying Hi-Res images, the version being compared as text * fix content-exact match line number off-by-one when the match starts at the first byte of a line (broot jumped to the line above) * new :no_action internal, doing nothing, which can be used to disable a key - Fix #328 * fix: detect a duplicate broot server name instead of silently overtaking the running server - Fix #1065 * fix preview transformers extension matching not working with double extensions such as .tar.gz - Fix #1195 * strip escape sequences from displayed names to prevent OSC injections - Fix #1188 * fall back to numeric uid/gid instead of ???? when the user or group name can't be resolved, which is always the case on statically linked musl builds - Fix #1075 * fix panic on a content regex matching the empty string at the end of a line ending with a control char (eg cr/$/ on a CRLF file) * fix Windows paths (containing backslashes) being mangled by the launcher's eval when using :cd and similar; also fixes escaping of paths containing a single quote - Fix #1100 * fix br failing on Windows/PowerShell when the temp path contains a space (e.g. a space in the Windows username) - Fix #788 * JPEG XL images are no longer previewed: the decoder had out-of-bounds bugs and the fix needs a more recent rustc (if you need it, tell me and I'll try to make it opt-in) * rustc minimal version changed from 1.83 to 1.85, and edition 2024 - v1.58.0 * change the way possible verb completions are listed, making it more readable when there are more than what fits the screen * fix argument of :select and :show being ignored in a --cmd sequence - Fix 1176 - v1.57.0 * help: verb 'keys' and 'description' columns now searchable - Fix #1163 * fix :print_path / :print_relative_path adding a trailing empty line when printing a multi-item staging area - Fix #1062 * Skin: attributes (bold, underlined, etc.) of the "selected_line" entry now applied - Fix #1156 * if no Wezterm version is found, broot now assumes it's recent enough to support kitty protocol for image - Fix #509 - v1.56.4 * fix compilation on non unix platforms (1.56.3 isn't available on those systems) - v1.56.3 * fix control characters sometimes remaining in the terminal after broot exit * nushell: rename br module to avoid conflict in last nushell version - Fix #1138 * :open_stay on the staging area opens every staged file through the system opener - Fix #444 - v1.56.2 * {file-root-relative} argument - Fix #1142 * fix :clear_stage (or other operations closing the stage panel) often closing broot - Fix #1143 - v1.56.1 * fix a typo in a verb in default conf - v1.56.0 * impacted_panel verb argument, allows the effect of a verb to be on another panel (eg to scroll the preview panel without removing the focus from the tree) - Fix #1119 * focus_panel_left and focus_panel_right internals - Fix #1115 * Major Feature: merge staged files to issue a single command: when a verb argument has a space-separated or comma-separated flag, a single external command is run even when the selection is multiple - Fix #465 The default verbs.json file has an example of a zip verb building an archive from all staged files. - v1.55.0 * activate Kitty Graphics Protocol to display Hi-Res images in iTerm2 * Tokyo Night skin ( https://github.com/Canop/broot/blob/main/resources/default-conf/skins/tokyo-night.hjson ) * matches related to several name patterns joined with and/or in a composite pattern are merged instead of having just the first one shown * nushell integration: switch $nu.temp-path to $nu.temp-dir - #1116 - v1.54.0 * fix crash on rendering B&W images with Kitty image protocol * don't match directories when a composite pattern has a content pattern, even negated (eg /js$/&!c/;: it's clear the user wants to match js files not containing a semicolon) - v1.53.0 * fix some cases of the verb not removed from the input on execution (with a risk of accidental double execution) * add the :filesystems (short :fs) verb and state on windows (it was already present on linux and mac). * improve the generation of preview pattern from

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size Two sites in vmwgfx_resource.c assign boolean literals to res->guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res->guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource's MOB allocation size: - vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true). Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated. Rename both assignments to guest_memory_dirty.

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: packet: use consistent hard_header_len in non-ring send paths () * kernel: net: ipv6: use-after-free in fib6_rule_suppress due to stale res->rt6 pointer (CVE-2026-74581) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: skip hash tables in u32_bind_class() u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check.