#git

### Summary The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk. ### Details In the `LossyDctDecoder_execute` function (from `src/lib/OpenEXRCore/internal_dwa_decoder.h`, when SSE2 is enabled), the following code is used to copy data from the chunks: ```cpp // no-op conversion to linear for (int y = 8 * blocky; y < 8 * blocky + maxY; ++y) { __m128i* restrict dst = (__m128i *) chanData[comp]->_rows[y]; __m128i const * restrict src = (__m128i const *)&rowBlock[comp][(y & 0x7) * 8]; for (int blockx = 0; blockx < numFullBlocksX; ++blockx) { _mm_storeu_si128 (dst, _mm_loadu_si128 (src)); // src += 8 * 8; // <--- si128 pointer incremented as a uint16_t dst += 8; } } ``` The issue arises because the `src` pointer, which is a `si128` pointer, is incremented by `8*8`, as if it were a `uint16_t` pointer...

### Summary The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a write operation when decompressing ZIPS-packed deep scan-line EXR files with a maliciously forged chunk header. ### Details When parsing `STORAGE_DEEP_SCANLINE` chunks from an EXR file, the following code (from `src/lib/OpenEXRCore/chunk.c`) is used to extract the chunk information: ```cpp if (part->storage_mode == EXR_STORAGE_DEEP_SCANLINE) // SNIP... cinfo->sample_count_data_offset = dataoff; cinfo->sample_count_table_size = (uint64_t) ddata[0]; cinfo->data_offset = dataoff + (uint64_t) ddata[0]; cinfo->packed_size = (uint64_t) ddata[1]; cinfo->unpacked_size = (uint64_t) ddata[2]; // SNIP... ``` By storing this information, the code that will later decompress and reconstruct the chunk bytes, will know how much space the uncompressed data will occupy. This size is carried along in the chain of decoding/decompression...

### Summary When parsing shader nodes in a MTLX file, the MaterialXCore code accesses a potentially null pointer, which can lead to crashes with maliciously crafted files. ### Details In `source/MaterialXCore/Material.cpp`, the following code extracts the output nodes for a given implementation graph: ```cpp InterfaceElementPtr impl = materialNodeDef->getImplementation(); if (impl && impl->isA<NodeGraph>()) { NodeGraphPtr implGraph = impl->asA<NodeGraph>(); for (OutputPtr defOutput : materialNodeDef->getOutputs()) { if (defOutput->getType() == MATERIAL_TYPE_STRING) { OutputPtr implGraphOutput = implGraph->getOutput(defOutput->getName()); for (GraphIterator it = implGraphOutput->traverseGraph().begin(); it != GraphIterator::end(); ++it) { ElementPtr upstreamElem = it.getU...

### Summary When parsing shader nodes in a MTLX file, the MaterialXCore code accesses a potentially null pointer, which can lead to crashes with maliciously crafted files. ### Details In `src/MaterialXCore/Material.cpp`, in function `getShaderNodes`, the following code fetches the output nodes for a given `nodegraph` input node: ```cpp // SNIP... else if (input->hasNodeGraphString()) { // Check upstream nodegraph connected to the input. // If no explicit output name given then scan all outputs on the nodegraph. ElementPtr parent = materialNode->getParent(); NodeGraphPtr nodeGraph = parent->getChildOfType<NodeGraph>(input->getNodeGraphString()); if (!nodeGraph) { continue; } vector<OutputPtr> outputs; if (input->hasOutputString()) { outputs.push_back(nodeGraph->getOutput(input->getOutputString())); // <--- null ptr is...

This week Bill connects the hype of literary awards to cybersecurity conference season. We highlight key insights from the Q2 2025 IR Trends report, including phishing trends, new ransomware strains, and top targeted sectors. Finally, check out all the places Talos will be at Black Hat.

Beware of Epsilon Red ransomware as attackers impersonate Discord, Twitch and OnlyFans using fake verification pages with .HTA files and ActiveX to spread malware.

The FSB cyberespionage group known as Turla seems to have used its control of Russia's network infrastructure to meddle with web traffic and trick diplomats into infecting their computers.

This appears to be a security vulnerability report describing a remote code execution (RCE) exploit in the ms-swift framework through malicious pickle deserialization in adapter model files. The vulnerability allows arbitrary command execution when loading specially crafted adapter models from ModelScope. This occurs when using machine torch version < 2.6.0, while ms-swift accepts torch version >= 2.0 **I. Detailed Description:** 1. Install ms-swift ``` pip install ms-swift -U ``` 2. Start web-ui ``` swift web-ui --lang en ``` 3. After startup, you can access [http://localhost:7860/](http://localhost:7860/) through your browser to see the launched fine-tuning framework program 4. Upload an adapter model repository (cyjhhh/lora_adapter_4_llama3) on ModelScope, where the lora/adapter_model.bin file is generated through the following code: ```python import torch, pickle, os class MaliciousPayload: def __reduce__(self): return (os.system, ("touch /tmp/malicious.txt",)) # A...

**I. Detailed Description:** 1. Install ms-swift ``` pip install ms-swift -U ``` 2. Start web-ui ``` swift web-ui --lang en ``` 3. After startup, access through browser at [http://localhost:7860/](http://localhost:7860/) to see the launched fine-tuning framework program 4. Fill in necessary parameters In the LLM Training interface, fill in required parameters including Model id, Dataset Code. The --output_dir can be filled arbitrarily as it will be modified later through packet capture 5. Click Begin to start training. Capture packets and modify the parameter corresponding to --output_dir You can see the concatenated command being executed in the terminal where web-ui was started 6. Wait for the program to run (testing shows it requires at least 5 minutes), and you can observe the effect of command execution creating files **II. Vulnerability Proof:** ``` /tmp/xxx'; touch /tmp/inject_success_1; # ``` **III. Fix Solution:** 1. The swift.ui.llm_train.llm...

## Description A Remote Code Execution (RCE) vulnerability exists in the [modelscope/ms-swift](https://github.com/modelscope/ms-swift) project due to unsafe use of `yaml.load()` in combination with vulnerable versions of the PyYAML library (≤ 5.3.1). The issue resides in the `tests/run.py` script, where a user-supplied YAML configuration file is deserialized using `yaml.load()` with `yaml.FullLoader`. If an attacker can control or replace the YAML configuration file provided to the `--run_config` argument, they may inject a malicious payload that results in arbitrary code execution. ## Affected Repository - **Project:** [modelscope/ms-swift](https://github.com/modelscope/ms-swift) - **Affect versions:** latest - **File:** `tests/run.py` - **GitHub Permalink:** https://github.com/modelscope/ms-swift/blob/e02ebfdf34f979bbdba9d935acc1689f8d227b38/tests/run.py#L420 - **Dependency:** PyYAML <= 5.3.1 ## Vulnerable Code ```python if args.run_config is not None and Path(args.run_config)....