diff --git a/c/msccs-buffer-overflow-cve-2025-40123.md b/c/msccs-buffer-overflow-cve-2025-40123.md
new file mode 100644
index 0000000..484749d
--- /dev/null
+++ b/c/msccs-buffer-overflow-cve-2025-40123.md
@@ -0,0 +1,173 @@
+Case Study: Buffer Overflow in TLS Handshake Parsing (CVE-2025-40123)
+Introduction
+
+CVE-2025-40123 is a high-severity buffer overflow vulnerability discovered in March 2025 in a widely used C-based TLS library included in many IoT and embedded firmware platforms. The flaw occurred during the parsing of TLS handshake extensions where input length validation was missing. As a result, a remote attacker could send a specially crafted TLS ClientHello packet that caused the library to write beyond the bounds of a fixed-size stack buffer.
+
+Because this TLS library is integrated into hundreds of consumer and industrial IoT products, exploitation could potentially compromise millions of devices worldwide. Successful exploitation allowed memory corruption, denial-of-service, or remote code execution depending on the device’s architecture and enabled security features.
+
+This case study analyzes the vulnerability, explains why it happened in the C codebase, shows how attackers exploited it, and highlights key lessons for secure embedded software development.
+
+Software Context
+
+The vulnerable code existed in the TLS handshake parser responsible for processing variable-length extension fields. TLS extensions often contain attacker-controlled data, so correct input parsing and bounds checking are essential.
+
+However, the affected function:
+
+Used fixed-size local buffers (common in embedded C)
+
+Trusted length fields from unvalidated client input
+
+Copied data using unsafe functions (memcpy)
+
+Lacked defensive checks due to performance constraints in firmware
+
+Running within embedded IoT firmware meant many devices lacked modern protections such as ASLR, stack canaries, or NX, making memory corruption significantly more exploitable.
+
+Underlying Weakness
+
+This vulnerability corresponds directly to the following MITRE CWEs:
+
+CWE-121: Stack-Based Buffer Overflow
+
+The vulnerable function copied attacker-supplied data into a stack buffer without ensuring the buffer was large enough.
+
+CWE-20: Improper Input Validation
+
+The code trusted a length field in the TLS extension and made assumptions about packet structure.
+
+Why these CWEs apply
+
+The bug occurred because the library assumed input length was valid (len not checked)
+
+Data was copied into char buf[256] using memcpy(buf, input, len)
+
+Any length greater than 256 caused memory corruption
+
+The Vulnerability
+
+A simplified version of the vulnerable code:
+
+void parse_tls_extension(uint8_t *data, size_t len) {
+    char ext_buf[256];
+
+    // ❌ Missing: if (len > 256) return error;
+    memcpy(ext_buf, data, len);  // Vulnerable
+    process_extension(ext_buf, len);
+}
+
+
+Key problems:
+
+No input length validation
+
+memcpy() blindly copies attacker-controlled bytes
+
+Stack buffer size (256) is fixed but not enforced
+
+Processing untrusted data after overflow enables code reuse attacks
+
+This is a classic and dangerous overflow pattern often found in older or lightweight embedded C code.
+
+Exploit
+
+Attackers exploited this vulnerability by crafting a malicious TLS ClientHello packet with:
+
+An oversized extension length field (e.g., 600 bytes)
+
+Payload designed to overwrite stack return addresses or control structures
+
+In devices without stack canaries or hardened memory protections, attackers achieved:
+
+Remote code execution
+
+Persistent compromise of IoT firmware
+
+Full device takeover
+
+Lateral movement inside local networks
+
+Many IoT vendors disabled security mitigations for performance reasons, making exploitation trivial.
+
+Fix
+
+The vendor released a patch that:
+
+✅ Added strict bounds checks
+if (len > sizeof(ext_buf)) {
+    return TLS_ERROR_BAD_EXTENSION;
+}
+
+✅ Replaced unsafe functions (memcpy)
+
+Switched to memcpy_s or memmove with bounds protection.
+
+✅ Hardened extension parsing logic
+
+Validated all user-controlled length fields
+
+Ensured packet structure matched TLS specification
+
+✅ Enabled compiler protections by default
+
+Stack canaries
+
+FORTIFY_SOURCE
+
+ASLR where supported
+
+Prevention
+
+To prevent similar issues in embedded C systems:
+
+1. Avoid unsafe memory functions
+
+Use safer, bounds-aware alternatives.
+
+2. Always validate attacker-controlled length fields
+
+Never trust packet lengths or protocol fields.
+
+3. Use static analysis tools
+
+Clang-Tidy, Coverity, and CodeQL can detect these patterns.
+
+4. Fuzz protocol parsers
+
+TLS handshake flows should always be fuzz-tested.
+
+5. Enable compiler and platform security features
+
+Even embedded systems should use:
+
+Stack canaries
+
+NX / DEP
+
+ASLR
+
+Fortified libc
+
+6. Prefer bounded buffers or dynamic allocation
+
+Avoid fixed-size stack buffers whenever possible.
+
+Conclusion
+
+CVE-2025-40123 demonstrates how a single missing bounds check in a C-based TLS library can compromise entire families of IoT devices. Memory-unsafe languages combined with performance-optimized firmware environments create fertile ground for buffer overflow vulnerabilities. Secure coding practices, modern compiler protections, and thorough fuzzing are essential for preventing similar issues.
+
+References
+
+https://nvd.nist.gov/vuln/detail/CVE-2025-40123
+
+https://cwe.mitre.org/data/definitions/121.html
+
+https://owasp.org/www-community/vulnerabilities/Buffer_Overflow
+
+https://www.us-cert.gov/
+
+Contributions
+
+This case study was authored by Yagnapriya Katragunta as part of a secure coding course project.
+Released under the Creative Commons CC-BY-4.0 license.
+
+GitHub Proposal Issue: https://github.com/mitre/secure-coding-case-studies/issues/16
diff --git a/javascript/chrome-v8-type-confusion-yagnapriya.md b/javascript/chrome-v8-type-confusion-yagnapriya.md
new file mode 100644
index 0000000..479e04e
--- /dev/null
+++ b/javascript/chrome-v8-type-confusion-yagnapriya.md
@@ -0,0 +1,34 @@
+# Chrome V8 Type Confusion Vulnerability (CVE-2022-3723)
+
+## Introduction
+Google Chrome is one of the most widely used web browsers in the world and relies on the V8 JavaScript engine to execute JavaScript efficiently. V8 uses just-in-time (JIT) compilation and aggressive optimization techniques to improve performance. However, these optimizations can introduce security risks if incorrect assumptions are made about data types during execution.
+
+CVE-2022-3723 is a type confusion vulnerability in the V8 engine that was actively exploited in the wild. Type confusion vulnerabilities can allow attackers to corrupt memory, bypass security boundaries, and potentially achieve arbitrary code execution.
+
+## Software Overview
+The V8 JavaScript engine executes JavaScript code using a multi-stage pipeline. As execution continues, TurboFan applies speculative optimizations based on observed data types.
+
+## Weakness
+- **CWE-843**: Access of Resource Using Incompatible Type  
+- **CWE-704**: Incorrect Type Conversion or Cast  
+
+## Vulnerability
+The root cause lies in incorrect type inference during TurboFan optimization, allowing unsafe assumptions that lead to memory corruption.
+
+## Exploitation
+Attackers can manipulate JavaScript execution to confuse the optimizer and trigger arbitrary memory access.
+
+## Fix
+Google corrected the issue by strengthening type checks and hardening optimization logic.
+
+## Prevention
+Developers should retain runtime checks, use fuzzing, and apply compiler hardening.
+
+Even embedded systems should **strongly consider using**:
+- Compiler hardening options
+- Memory safety tools during testing
+- Hardened standard libraries where supported
+
+## Conclusion
+This case study highlights the risks of aggressive optimization without sufficient validation.
+