Memory safety — overflow-এর ধারণা, mitigation আর নিরাপদ ভাষা

১ · Memory safety কী — ব্যাংকের লকার আর দুটি নিয়ম

ব্যাংকের লকার-কক্ষের কথা ভাবুন। লম্বা সারিতে ছোট ছোট লকার, প্রতিটি একজন গ্রাহকের। এখানে দুটি নিয়ম। প্রথম, আপনি শুধু নিজের লকার খুলবেন, পাশেরটি নয়। দ্বিতীয়, লকারের মেয়াদ শেষে চাবি জমা দেবেন। পরে সেই লকার অন্য গ্রাহক পেলে পুরোনো চাবি আর চলবে না।

কম্পিউটারের memory-ও পাশাপাশি রাখা ঘরের সারি। প্রোগ্রামের একটি অংশ যখন একটি pointer দিয়ে কোনো ঘরে হাত দেয়, তখন একই দুটি প্রশ্ন ওঠে। ঘরটি কি তার সীমার ভেতরে? ঘরটি কি এখনো তার? Memory safety মানে প্রোগ্রাম এই দুই প্রশ্নের উত্তর সবসময় ঠিক রাখে। প্রথম নিয়মকে বলে spatial safety, অর্থাৎ জায়গার নিরাপত্তা। দ্বিতীয়টি temporal safety, অর্থাৎ সময়ের নিরাপত্তা।

সংজ্ঞা নিয়ে একটু মতভেদ আছে। কেউ memory safety বলতে শুধু এই দুই সীমা বোঝান। কেউ এর সঙ্গে uninitialized memory পড়া, ভুল type হিসেবে memory পড়া, এমনকি কিছু data race-ও ধরেন। প্রকাশিত হিসাব পড়ার সময় তাই দেখে নেবেন, কে কোন সংজ্ঞায় গুনেছেন।

C-তে এসব ভুলের ফল undefined behavior: ভাষার নিয়ম কোনো ফলের কথাই বলে না। Stack আর heap-এর বিন্যাস, UB-র খুঁটিনাটি আর integer overflow আমরা আবার করব না, এগুলো আছে C কোর্সের Undefined behavior আর নিরাপদ কোড পর্বে। এই পর্বের প্রশ্ন আলাদা: একজন রক্ষক এই ঝুঁকি কীভাবে মাপবেন, কমাবেন আর ধীরে ধীরে সরাবেন।

২ · বাগের পরিবার — ছয়টি ভুল আর সীমা যাচাই

প্রথমে পুরো পরিবারটি এক টেবিলে দেখে নিন। প্রতিটি সারিতে আছে ভুলটি কী, সাধারণত কী ক্ষতি হয়, আর কোন জিনিস একে সবচেয়ে ভালো ঠেকায়।

টেবিলের ক্ষতি মানে সম্ভাব্য ক্ষতি। প্রতিটি বাগ exploit করা যায় না, আর সব বাগ সমান গুরুতর নয়। তবে রক্ষক হিসেবে “এটি কাজে লাগানো যায় না” ধরে নেওয়া বিপজ্জনক। তাই আগে ঠিক করুন, পরে তর্ক করুন।

এবার সবচেয়ে সরল প্রতিরোধটি দেখি: bounds check, অর্থাৎ প্রতিটি প্রবেশের আগে সীমা যাচাই। খেলনা memory-তে cart-এর চারটি ঘর (mem[0] থেকে mem[3]), আর ঠিক পাশের ঘরে price রাখা আছে।

1const SIZE = 4;  // mem[4] = price2function write(i, v) {3  if (i < 0 || i >= SIZE) return "REFUSED";4  mem[i] = v;5  return "ok";6}

একই ঘটনাটি নিজে চালিয়ে দেখুন। এটি একটি simulation: সাধারণ JavaScript array-কে memory ধরে নেওয়া হয়েছে, আসল memory-তে কিছুই ঘটছে না।

// SIMULATION: a plain JS array pretends to be memory. No real memory is touched.
const SIZE = 4;                     // cart has 4 cells: mem[0]..mem[3]
function newMemory() {
  return [0, 0, 0, 0, 120];         // mem[4] is a neighbouring toy variable: price
}
const show = m => `cart=[${m.slice(0, SIZE)}] price=${m[SIZE]}`;

function checkedWrite(m, i, v) {
  if (!Number.isInteger(i) || i < 0 || i >= SIZE) return 'REFUSED';
  m[i] = v;
  return 'ok';
}
function uncheckedWrite(m, i, v) {
  m[i] = v;                         // nobody asks whether i belongs to cart
  return 'ok';
}

const writes = [[1, 5], [3, 2], [4, 9]];   // the last index is outside cart
for (const [label, fn] of [['checked', checkedWrite], ['unchecked', uncheckedWrite]]) {
  const m = newMemory();
  console.log(`--- ${label} build ---`);
  for (const [i, v] of writes) {
    console.log(`write cart[${i}] = ${v} -> ${fn(m, i, v)}`);
  }
  console.log(show(m));
  console.log(`total for 5 items = ${5 * m[SIZE]}`);
}

৩ · সময়ের ভুল — use-after-free ধরার ধারণা

হোটেলের রুম-কার্ডের কথা ভাবুন। অতিথি check-out করলেন, কিন্তু কার্ড পকেটে থেকে গেল। ভালো হোটেলে কার্ডে একটি ক্রমিক সংখ্যা থাকে। নতুন অতিথি এলে দরজা নতুন সংখ্যা মানে, পুরোনো কার্ড আর খোলে না। কার্ড যদি এমন যাচাই ছাড়া কাজ করত, পুরোনো অতিথি নতুন অতিথির ঘরে ঢুকে পড়তেন।

Use-after-free ঠিক তা-ই। Memory free হলে heap-এর সেই জায়গা আবার কাজে লাগে। পুরোনো pointer জানে না যে মালিক বদলে গেছে। নিচে একটি খেলনা tracker প্রতিটি ঘরে “generation” নামের ক্রমিক সংখ্যা রাখে, ঠিক কার্ডের সংখ্যার মতো।

// SIMULATION: a toy allocator with generation numbers. Not a real heap.
const slots = [{ gen: 1, data: null, live: false }];   // one slot, so reuse is certain
const log = (s, r) => console.log(s.padEnd(24) + r);

function alloc(data) {
  const s = slots[0];
  s.data = data; s.live = true;
  return { slot: 0, gen: s.gen };          // a handle remembers the generation
}
function check(h) {
  const s = slots[h.slot];
  if (h.gen !== s.gen) return s.live ? 'STALE' : 'FREED';
  return s.live ? 'OK' : 'FREED';
}
function read(h, tracked) {
  if (tracked && check(h) !== 'OK') return `refused (${check(h)})`;
  return `"${slots[h.slot].data}"`;
}
function free(h) {
  if (check(h) !== 'OK') return `refused double free (${check(h)})`;
  const s = slots[h.slot];
  s.live = false; s.data = null; s.gen += 1;  // every old handle is now stale
  return 'freed';
}

const a = alloc('order-A');
log('read a', read(a, true));
log('free a', free(a));
log('read a after free', read(a, true));
log('free a again', free(a));
const b = alloc('session-B');              // same slot is reused
log('read b', read(b, true));
log('read a, no tracker', read(a, false)); // wrong owner's data
log('read a, tracker', read(a, true));

লক্ষ করুন, temporal ভুল ধরতে সীমা যাচাই যথেষ্ট নয়। a যে জায়গা দেখছে, সেটি বৈধ memory-র ভেতরেই। ভুল হলো সময়ে। এজন্যই রক্ষকের কাছে দুটি প্রশ্ন আলাদা: “এই ঘরটি কি সীমার ভেতরে?” আর “এই ঘরের মালিক কি এখনো আমি?”

৪ · কেন এত গুরুত্ব — প্রকাশিত সংখ্যা আর Heartbleed

Memory ভুল শুধু একটি বাগের ধরন নয়, এটি একটি বড় অংশের vulnerability-র উৎস। কিন্তু সংখ্যা পড়তে হয় সাবধানে। নিচের টেবিলে দেখুন, প্রতিটি হিসাব কী গুনেছে।

দুটি সতর্কতা। প্রথমত, প্রথম দুটি সংখ্যা বড়, পুরোনো C ও C++ কোডের। একটি Python ওয়েবসাইটের ঝুঁকির ছবি এমন নয়, সেখানে injection বা ভুল অনুমতি অনেক বেশি প্রাসঙ্গিক। দ্বিতীয়ত, সংখ্যাগুলো প্রতিষ্ঠানের নিজের প্রকাশ করা হিসাব, মাপার নিয়মও এক নয়। তবু আলাদা প্রতিষ্ঠানের হিসাব একই দিকে দেখায়, তাই ধারণাটি উপেক্ষা করা যায় না।

তাহলে ওয়েব বা ব্যবসায়িক software লেখক কেন ভাববেন? কারণ আপনার কোড একা চলে না। ছবি resize করার library, TLS library, database engine, browser, OS kernel, ফোনের media parser, এসবের অনেকটাই C বা C++-এ লেখা। আপনার attack surface-এর ভেতরে এই কোডও আছে। এজন্য পর্ব ৩২-এর patch ব্যবস্থা এখানে সরাসরি কাজে লাগে।

রক্ষকের শিক্ষা তিনটি। প্রতিরোধ: অন্য পক্ষের দাবি করা দৈর্ঘ্য কখনো বিশ্বাস নয়, আসল ডেটার সঙ্গে মেলানো। Detection: এমন ফাঁস স্বাভাবিক log-এ প্রায় চিহ্ন রাখে না, তাই release-এর আগে খোঁজাই ভালো। ২০১৫ সালে Hanno Böck লেখেন, afl fuzzer দিয়ে ছয় ঘণ্টার মধ্যে ত্রুটিটি আবার পাওয়া গিয়েছিল। সাড়া: secret ফাঁস হয়ে থাকতে পারে ধরে নিয়ে সব বদলানো। C-র দিক থেকে একই ঘটনা আছে C কোর্সের সেই পর্বে।

৫ · Mitigation — বাগ সারায় না, খরচ বাড়ায়

বাড়ির দেয়ালে একটি ফাটল আছে। জানালায় গ্রিল, গেটে দারোয়ান আর CCTV চোরের কাজ কঠিন করে, কিন্তু ফাটলটি জোড়া লাগে না। Mitigation-ও তেমনি। সে বাগটি সরায় না, বাগ থেকে বড় ক্ষতিতে পৌঁছানোর পথ কঠিন করে। পর্ব ৩-এর defense in depth এখানে ঠিক খাটে।

ঠিক এই কারণেই Heartbleed-এর সময় canary বা NX কিছু করতে পারেনি: সেখানে কোড বা চলার পথ বদলায়নি, শুধু memory পড়া হয়েছিল। Mitigation কাজ করে নির্দিষ্ট পথে, বাগের পুরো পরিবারে নয়।

ছোট হিসাব: ASLR-এর entropy

ASLR-এর শক্তি মাপা হয় entropy-তে, মানে কত bit এলোমেলো। ধরুন একটি memory অঞ্চলে ২৮ bit entropy আছে। তাহলে সম্ভাব্য অবস্থান 2²⁸ = 268,435,456টি, আর এক চেষ্টায় মিলে যাওয়ার সম্ভাবনা 1/2²⁸ ≈ 3.7 × 10⁻⁹. এবার ধরুন একটি পুরোনো ৩২-bit সিস্টেমে মাত্র ৮ bit: অবস্থান 256টি, সম্ভাবনা 1/256 ≈ 0.39%. দুটির ব্যবধান 2²⁰ = 1,048,576 গুণ। সংখ্যাগুলো ধরে নেওয়া, আসল মান OS, CPU আর memory অঞ্চল অনুযায়ী আলাদা। রক্ষকের জন্য ব্যবহারিক কথা হলো: একটি সেবা বারবার crash করে নিজে থেকে আবার চালু হতে থাকলে সেটিকে স্বাভাবিক ধরবেন না, এটি তদন্তের সংকেত।

এবার স্তরগুলো একসঙ্গে দেখুন। ধরুন একটি কাল্পনিক অনলাইন বাজারের ছবি-প্রক্রিয়ার C কোডে heap-এ একটি out-of-bounds লেখার ভুল আছে। লক্ষ রাখুন, শেষ ধাপের আগে প্রথম সারির উত্তর একবারও বদলায় না।

এবার একটি খেলনা coverage টেবিল চালান। এটি পরিমাপ নয়, শুধু শেখার মডেল: চারটি কাল্পনিক binary আর সরল করে ধরা বিচার।

// Teaching model, not a measurement. Fictional binaries, simplified judgements.
const bugs = ['stack-write', 'heap-write', 'oob-read', 'uaf', 'double-free', 'uninit'];
// P = prevented by design, D = often detected or stopped at run time, C = cost raised
const covers = {
  canary:    { 'stack-write': 'D' },
  fortify:   { 'stack-write': 'D', 'heap-write': 'D', 'oob-read': 'D' },
  aslr_nx:   { 'stack-write': 'C', 'heap-write': 'C', uaf: 'C', 'double-free': 'C' },
  cfi:       { 'stack-write': 'C', 'heap-write': 'C', uaf: 'C' },
  allocator: { 'heap-write': 'C', uaf: 'C', 'double-free': 'D' },
  safe_lang: Object.fromEntries(bugs.map(b => [b, 'P'])),
};
const binaries = {
  'legacy-daemon': [],
  'billing-hardened': ['canary', 'fortify', 'aslr_nx'],
  'gateway-layered': ['canary', 'fortify', 'aslr_nx', 'cfi', 'allocator'],
  'parser-rust': ['safe_lang', 'aslr_nx'],
};
const rank = { '-': 0, C: 1, D: 2, P: 3 };
const best = (list, bug) => list.reduce((b, m) => {
  const v = covers[m][bug] || '-';
  return rank[v] > rank[b] ? v : b;
}, '-');

console.log('binary'.padEnd(18) + bugs.map(b => b.padEnd(12)).join(''));
for (const [name, list] of Object.entries(binaries)) {
  const row = bugs.map(b => best(list, b));
  const open = row.filter(v => v === '-').length;
  console.log(name.padEnd(18) + row.map(v => v.padEnd(12)).join('') + `gaps=${open}`);
}

৬ · নিজের কোডে — flag, sanitizer, Valgrind আর fuzzing

দুই ধরনের কাজ আলাদা রাখুন। খোঁজা হয় test-এ, যেখানে ধীর হলেও চলে। শক্ত করা হয় release build-এ, যেখানে খরচ কম হতে হয়। Flag-গুলোর পূর্ণ ব্যাখ্যা আছে C কোর্সের পর্বে, আর sanitizer ও Valgrind-এর হাতে-কলমে ব্যবহার আছে C debugging পর্বে। এখানে শুধু নিরাপত্তার মানচিত্র।

# উদাহরণ: test build, শুধু নিজের কোডে
gcc -g -O1 -Wall -Wextra -fsanitize=address,undefined \
    -fno-omit-frame-pointer app.c -o app_test

# উদাহরণ: release build, শুধু নিজের কোডে
gcc -O2 -Wall -Wextra -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 \
    -fstack-protector-strong -fPIE -pie app.c -o app

# নিজের build সত্যিই hardened কি না দেখা
readelf -h app | grep 'Type:'        # DYN মানে সাধারণত PIE
readelf -lW app | grep GNU_STACK     # শেষে RW, RWE নয়: stack চালানো যায় না
readelf -sW app | grep stack_chk     # canary-র চিহ্ন, থাকলে দেখা যাবে

এই কমান্ডগুলো এই পাতায় চালানো হয়নি, তাই আউটপুট দেখানো হলো না। =3 নতুন GCC ও glibc-তে কাজ করে, পুরোনো toolchain-এ =2 ব্যবহার করুন। ASan release build-এ রাখার মতো hardening নয়, এটি বাগ খোঁজার টুল।

ASan-এর report পড়া শেখা দরকারি। নিচে use-after-free-এর একটি সরল নমুনা। এটি চালানো কোনো প্রোগ্রামের হুবহু আউটপুট নয়, শুধু আকার বোঝানোর জন্য বানানো।

নমুনা আউটপুট — version-ভেদে আলাদা হতে পারে

ERROR: AddressSanitizer: heap-use-after-free
READ of size 4
    #0 in show_order order.c:21
freed by thread T0 here:
    #0 in free
    #1 in close_order order.c:14
previously allocated by thread T0 here:
    #0 in malloc
    #1 in open_order order.c:8

তিনটি অংশ তিনটি প্রশ্নের উত্তর দেয়: কোথায় ভুল ব্যবহার হলো (order.c:21), কোথায় free হয়েছিল (order.c:14), আর কোথায় বরাদ্দ হয়েছিল (order.c:8). সমাধান শুরু হয় একটি প্রশ্ন দিয়ে: এই memory-র মালিক আসলে কে, আর সে কখন ছেড়ে দেবে?

৭ · C আর C++-এ নিরাপদ অভ্যাস

পুরোনো কোড রাতারাতি বদলায় না, তাই C আর C++-এর ভেতরেই ঝুঁকি কমাতে হয়। মূল নীতি একটি: দৈর্ঘ্য আর মালিকানা যেন ডেটার সঙ্গেই চলে, মানুষের মাথায় নয়।

/* উদাহরণ: দৈর্ঘ্য বিশ্বাস করার আগে যাচাই */
int copy_name(char *dst, size_t cap, const char *src, size_t len) {
    if (dst == NULL || src == NULL) return -1;
    if (cap == 0 || len >= cap) return -1;   /* '\0'-এর জন্য এক ঘর লাগে */
    memcpy(dst, src, len);
    dst[len] = '\0';
    return 0;                                /* কলকারী ফল দেখবেন */
}

// উদাহরণ: সীমা আর মালিকানা type-এর ভেতরে
#include <memory>
#include <span>
#include <vector>

struct Order { int id; };

void clear_cart(std::span<int> cart) {    // pointer আর size একসঙ্গে
    for (int &item : cart) item = 0;      // সীমার বাইরে যাওয়ার সূচক নেই
}

int main() {
    std::vector<int> cart(4);
    clear_cart(cart);
    cart.at(2) = 5;                       // ভুল সূচকে exception, নীরব ক্ষতি নয়
    auto order = std::make_unique<Order>();  // একজন মালিক, আপনাআপনি মুক্ত
    order->id = 47;
}

Smart pointer-এর বিস্তারিত আছে C++ কোর্সের RAII পর্বে। এগুলো ভালো অভ্যাস, তবে নিশ্চয়তা নয়। Vector বড় হলে পুরোনো reference নষ্ট হতে পারে, compiler সবসময় তা ধরে না। আর SEI CERT C-র মতো coding standard আর SAST টুল এই নিয়মগুলো দলে ধরে রাখতে সাহায্য করে। সাধারণ secure coding-এর নিয়ম আছে পর্ব ৪৬-এ।

৮ · Memory-safe ভাষা — চারটি পথ আর তার দাম

Memory-safe language সুরক্ষাকে লেখকের মনোযোগ থেকে সরিয়ে ভাষার নিয়মে নিয়ে আসে। পথ প্রধানত দুটি। একটি garbage collector: কোনো কিছু আর ব্যবহার হচ্ছে না, তা runtime নিজে দেখে memory ফেরত নেয়। অন্যটি Rust-এর পথ: compile-এর সময় মালিকানা যাচাই।

// উদাহরণ: এই কোড ইচ্ছা করেই compile হয় না
fn main() {
    let order = String::from("order-A");
    let moved = order;          // মালিকানা moved-এর কাছে গেল
    println!("{order}");        // error[E0382]: borrow of moved value
    println!("{moved}");
}

এখানে কোনো ভুল চালানোর সময় ঘটে না, প্রোগ্রাম তৈরিই হয় না। এটিই compile-time নিশ্চয়তা। তবে চার ভাষার সুরক্ষা আর দাম এক নয়:

Python-এর সুরক্ষা নিজে দেখুন। লক্ষ করবেন, memory নিরাপদ থাকলেও যুক্তির ভুল আপনাকেই ধরতে হয়।

# Python keeps memory safe, but it does not check your logic for you.
cart = [10, 20, 30, 40]
price = 120                       # a separate object, not a neighbouring cell

try:
    cart[4] = 9
except IndexError as e:
    print("write refused:", e)
try:
    print(cart[4])
except IndexError as e:
    print("read refused:", e)
print("cart:", cart, "price:", price)

# A toy record: the sender CLAIMS a length, and the real payload is shorter.
def naive_echo(payload, claimed):
    return payload[:claimed]      # a slice stops at the end, no exception

def safe_echo(payload, claimed):
    if claimed < 0 or claimed > len(payload):
        return None               # discard: the claim does not match the data
    return payload[:claimed]

payload = b"hello"
for claimed in (5, 300):
    print(f"claimed={claimed}:", "naive", naive_echo(payload, claimed),
          "| safe", safe_echo(payload, claimed))
print("negative index:", cart[-1])  # valid in Python, but is it what you meant?

৯ · পুরোনো কোডের পথ — নির্দেশিকা, Android-এর ফল আর migration

“নতুন করে সব লিখে ফেলি” শুনতে সহজ, কিন্তু বাস্তবে এটি বিরল পথ। আগে দেখি সরকারি নির্দেশিকা আর একটি বড় প্রকল্পের অভিজ্ঞতা কী বলে।

এগুলো যুক্তরাষ্ট্রের সংস্থার পরামর্শ, বাংলাদেশের কোনো আইন নয়। তবে দিকটি বোঝার জন্য কাজে লাগে।

Android-এর প্রকাশিত ফল

Google জানিয়েছে, Android-এ memory safety ত্রুটির ভাগ ২০১৯-এর ৭৬% থেকে ২০২৪-এ ২৪%-এ নামে, আর ২০২৫-এ প্রথমবার ২০%-এর নিচে। উল্লেখযোগ্য দিক হলো, কৌশলটি পুরোনো কোড নতুন করে লেখা নয়, বরং নতুন কোড memory-safe ভাষায় লেখা। Google-এর ব্যাখ্যায় ত্রুটি কোডের বয়সের সঙ্গে দ্রুত কমে, তাদের কথায় এর একটি half-life আছে (vulnerability half-life), তাই ঝুঁকির বড় অংশ নতুন কোডে।

সেই একটি ঘটনাও শিক্ষণীয়। Google জানায়, CrabbyAVIF নামের Rust-এর একটি অংশের unsafe কোডে linear buffer overflow পাওয়া গিয়েছিল। Android-এর Scudo hardened allocator সেটিকে কাজে লাগানোর অযোগ্য করে দেয়, আর ত্রুটিটি প্রকাশের আগেই সারানো হয়। অর্থাৎ নিরাপদ ভাষাতেও ফাঁক থাকে, আর mitigation-এর স্তর তখনও কাজে আসে।

একটি বাস্তব migration পরিকল্পনা

1. তালিকা: কোন C ও C++ অংশ আছে, কারা অবিশ্বস্ত ইনপুট নেয়, কার legacy মালিক নেই, তা লিখে ফেলুন।
2. অগ্রাধিকার: ঝুঁকি মাপুন। আগে network-মুখী parser, ছবি ও ফাইলের format, cryptography-র সীমানা। পর্ব ৪-এর threat model এখানে কাজে লাগে।
3. নতুন ঝুঁকি থামান: নতুন অংশ memory-safe ভাষায় লেখার নিয়ম করুন। ব্যতিক্রম লিখিত থাকুক।
4. বর্তমানকে শক্ত করুন: Hardening flag, CI-তে sanitizer আর fuzzing, ঝুঁকির অংশ sandbox-এ।
5. সীমানা বানান: নতুন আর পুরোনো কোডের মাঝে ছোট, পরিষ্কার FFI সেতু। সেতুটিও নিজে একটি ঝুঁকি, তাই সরল রাখুন।
6. বেছে বেছে সরান: সবচেয়ে ঝুঁকির ছোট অংশগুলো একে একে বদলান, আর পুরোনো অংশ বন্ধ করুন।
7. মাপুন ও প্রকাশ করুন: নতুন কোডে memory-safe ভাষার ভাগ, memory ত্রুটির সংখ্যা, fuzz coverage. Roadmap-এ অগ্রগতি লিখে রাখুন।

১০ · AI-এর যুগে — memory safety-তে AI-কে যাচাই করা

AI খুব দ্রুত C কোড লেখে আর Rust-এ অনুবাদও করে। কিন্তু memory ভুল অনেক সময় test পাস করা কোডেই লুকিয়ে থাকে। তাই AI-এর উত্তরকে একজন নতুন সহকর্মীর খসড়া ভাবুন।

AI-এর পরামর্শ গ্রহণের চেকলিস্ট

• Diff নিজে পড়েছি, আর প্রতিটি সীমা ও free-র কারণ বলতে পারি
• -Wall -Wextra-এ warning নেই, কোনো flag বন্ধ করা হয়নি
• ASan আর UBSan-সহ নিজের ল্যাবে test চালিয়েছি, সীমার মানও দিয়েছি
• নতুন unsafe বা কাঁচা pointer থাকলে তার কারণ লেখা আছে
• উল্লেখ করা CVE আর নির্দেশিকা মূল উৎসে মিলিয়েছি
• Prompt-এ কোনো secret বা ব্যক্তিগত তথ্য দিইনি
• মানুষের ওপর প্রভাব ফেলে এমন triage সিদ্ধান্ত মানুষই নিয়েছে