Linux SMB uygulamasında o3 kullanılarak uzaktan 0-day bulundu

 (sean.heelan.io)
2 puan yazan GN⁺ 2025-05-25 | 1 yorum | WhatsApp'ta paylaş
  • Linux çekirdeğinin SMB3 sunucu uygulaması olan ksmbd denetiminde yalnızca OpenAI o3 API kullanılarak uzaktan use-after-free zafiyeti CVE-2025-37899 bulundu; ayrıca bir ajan çatısı ya da araç kullanılmadı
  • Zafiyet, SMB logoff komutu işlenirken serbest bırakılmış sess->user nesnesine başka bir iş parçacığının erişmeye devam edebilmesinden kaynaklanıyor; bunun ortaya çıkması için eşzamanlı bağlantılar ve paylaşılan oturum durumu birlikte değerlendirilmeliydi
  • Elle bulunmuş CVE-2025-37778 temel alınarak yapılan kıyaslamada o3, 100 denemenin 8'inde zafiyeti buldu; Claude Sonnet 3.7 3 kez, Claude Sonnet 3.5 ise 0 kez buldu
  • Girdi tüm SMB komut işleyicileri ve bağlantı işleme koduna kadar genişletildiğinde, yani 12k LoC / 100k girdi tokeni koşulunda mevcut zafiyetin bulunma oranı 100 denemede 1'e düştü; ancak aynı sonuç kümesinde yeni zafiyet CVE-2025-37899 da ortaya çıktı
  • Hâlâ çok sayıda yanlış pozitif ve anlamsız çıktı var, ancak gerçek zafiyet araştırmalarında insan tarafından incelenip doğrulanmaya değecek kadar doğru sonuca ulaşma olasılığı yükselmiş durumda

o3 ile ksmbd zafiyeti bulma deneyi

  • Denetim hedefi, Linux çekirdek alanında SMB3 protokolü dosya paylaşımını uygulayan ksmbd idi
  • OpenAI o3 modeli o3 API üzerinden çağrıldı; ek bir iskelet yapı, ajan çatısı ya da araç kullanılmadı
  • Bulunan zafiyet CVE-2025-37899 ve düzeltme Linux çekirdek commit'inde yer alıyor
  • Temel sorun, SMB logoff komut işleyicisindeki use-after-free; referans sayımı olmayan bir nesne başka bir iş parçacığı tarafından erişilebilir durumdayken serbest bırakılıyor
  • Bu zafiyetin bulunabilmesi için sunucuya yönelik eşzamanlı bağlantıların ve belirli durumlarda paylaşılan nesnelerin birlikte anlaşılması gerekiyor
  • Açıkça kamuya tartışılmış örnekler içinde, bu tür bir zafiyetin bir LLM tarafından bulunduğu ilk vaka gibi göründüğü değerlendirmesi de yer alıyor

Referans zafiyet CVE-2025-37778

  • Önce elle bulunmuş CVE-2025-37778, o3 performansını değerlendirmek için kıyaslama olarak kullanıldı
  • Bu zafiyet, Kerberos kimlik doğrulama yolunda uzak istemcinin session setup isteği işlenirken ortaya çıkan bir use-after-free
  • krb5_authenticate, sess->state == SMB2_SESSION_VALID ise sess->user nesnesini serbest bırakıyor
  • Sonraki kod, ksmbd_krb5_authenticate fonksiyonunun bunu yeniden geçerli bir değerle başlatacağına ya da -EINVAL döndükten sonra sess->user kullanılmayacağı varsayımına dayanıyor
  • Gerçekte ise ksmbd_krb5_authenticate fonksiyonunun sess->user değerini yeniden başlatmaması sağlanabiliyor ve krb5_authenticate -EINVAL döndürse bile sess->user erişilebilir kalabiliyor

Kıyaslama kurulumu ve prompt

  • CVE-2025-37778 uzak saldırı yüzeyinde bulunuyor ve sess->state == SMB2_SESSION_VALID koşulunun sağlanması, yeniden başlatılmayan yolun ve serbest bırakma sonrası erişim yolunun birlikte değerlendirilmesi gerektiği için kıyaslama olarak kullanıldı
  • Zafiyet yolunu açıklamak için gereken en küçük kodun yaklaşık 3.3k LoC olduğu hesaplandı
  • Deney girdisi, session setup komut işleyicisini ve bu işleyicinin çağırdığı işlevleri çağrı derinliği 3'e kadar içeriyordu
  • Paket alımı, istek ayrıştırma, komut işleyici seçimi ve işleyici tamamlandıktan sonraki bağlantı temizleme kodu da veri yapılarının nasıl başlatıldığına dair tahmini azaltmak için eklendi
  • Nihai girdi yaklaşık 3.3k LoC / 27k token idi ve analiz edilen dosya session_setup_code.prompt olarak yayımlandı
  • Prompt şu koşulları içeriyordu
    • use-after-free zafiyetlerini bulması talimatı verildi
    • ksmbd'nin rolü, mimarisi ve tehdit modeli yüksek seviyede sağlandı
    • Yanlış pozitif raporlamaktansa raporlamamayı tercih etmesi güçlü biçimde yönlendirildi
  • Tam prompt dosyası o3_finds_cve-2025-37899 deposunda yer alıyor
  • Çalıştırmak için Simon Willison'ın llm aracı kullanıldı

CVE-2025-37778 kıyaslama sonuçları

  • Deney düzeneği aynı sorguyu 100 kez çalıştırıp sonuçları kaydetti
  • o3, CVE-2025-37778'i 100 denemenin 8'inde buldu
  • 66 denemede hata olmadığı sonucuna vardı ve bunlar false negative oldu
  • Kalan 28 deneme false positive idi
  • Karşılaştırma sonuçları şöyleydi
    • Claude Sonnet 3.7: 100 denemede 3 bulgu
    • Claude Sonnet 3.5: 100 denemede 0 bulgu
  • Bu kıyaslamada o3, Claude Sonnet 3.7'ye göre 2~3 kat daha iyi sonuç gösterdi
  • Örnek raporlar o3 sonucu ve Sonnet 3.7 sonucu olarak yayımlandı
  • o3 çıktısı, yapısı ve odağı nedeniyle insan tarafından yazılmış kısa bir hata raporu gibi okunuyor, ancak bazen fazla kısa olduğundan netliği düşebiliyor
  • Sonnet 3.7 çıktısı ise düşünce akışı ya da çalışma günlüğüne daha yakın bir biçimde görünüyor

Tüm komut işleyicilerine genişletilen deney

  • Sonraki deneyde o3'e yalnızca session setup işleyicisi değil, tüm SMB komut işleyicileri verildi
  • Komut işleyicileri smb2pdu.c içinde yer alıyor ve dosya boyutu yaklaşık 9k LoC
  • Tüm işleyiciler, bağlantı kurulum ve temizleme kodu ile komut işleyici dağıtım rutini birlikte yaklaşık 12k LoC / 100k girdi tokeni ediyor
  • Bu koşulda da deney 100 kez çalıştırıldı
  • o3, mevcut Kerberos kimlik doğrulama zafiyeti CVE-2025-37778'i 100 denemenin yalnızca 1'inde buldu ve girdi token sayısı arttıkça performans düşüşü belirginleşti
  • Aynı sonuç kümesinde daha önce bilinmeyen yeni zafiyet CVE-2025-37899 raporu bulundu

CVE-2025-37899'un zafiyet yolu

  • Yeni zafiyet de sess->user serbest bırakılmasıyla ilgili, ancak bu kez session logoff işleyicisinde ortaya çıkıyor
  • smb2_session_logoff şu sırayla çalışıyor
    • ksmbd_close_session_fds(work) çağrılır
    • ksmbd_conn_wait_idle(conn) çağrılır
    • Oturum durumu SMB2_SESSION_EXPIRED olarak ayarlanır
    • sess->user varsa ksmbd_free_user(sess->user) ile serbest bırakılır ve sess->user = NULL yapılır
  • o3 raporundaki zafiyet senaryosu şöyle
    • SMB 3.0 ve üstünde ikinci taşıma mevcut bir oturuma bağlanır ve conn->binding == true olur
    • Worker-A başka bir bağlantı C2 üzerinde WRITE gibi normal bir isteği işler
    • smb2_check_user_session(), mevcut struct ksmbd_session işaretçisini work->sess içine kaydeder ve oturum referans sayısını artırır, ancak sess->user için ayrı bir referans tutmaz
    • Worker-B ilk bağlantı C1 üzerinden aynı oturum için SMB2 LOGOFF işler ve smb2_session_logoff() çalıştırır
    • ksmbd_conn_wait_idle(conn), yalnızca o bağlantıdaki çalışan istekleri bekler; aynı oturumu kullanan başka bağlantıların isteklerini beklemez
    • Worker-A çalışmaya devam eder ve user_guest(sess->user), ksmbd_compare_user(sess->user, …), sess->user->uid gibi erişimler yapabilir
  • Zamanlamaya bağlı olarak bu, serbest bırakılmış slab nesnesini işaret eden bir use-after-free olabilir ya da sess->user = NULL sonrasında okuma yapılırsa NULL dereference ile DoS'a dönüşebilir

Hatalı düzeltme önerisi ve o3 sonuçlarının değeri

  • CVE-2025-37778 için ilk önerilen düzeltme, ksmbd_free_user(sess->user) sonrasına sess->user = NULL eklemekti
  • CVE-2025-37899 raporu okunduktan sonra bunun yetersiz olduğu ortaya çıktı
  • logoff işleyicisi zaten sess->user = NULL yapıyor, ancak SMB protokolü iki farklı bağlantının aynı oturuma bağlanmasına izin verdiği için sistem yine de zafiyetli kalıyor
  • Kerberos kimlik doğrulama yolunda da sess->user serbest bırakıldıktan hemen sonra NULL yapılmadan önceki kısa pencerede başka bir iş parçacığı erişebilir
  • o3'ün bazı raporları aynı hatayı yaptı, ancak bazıları oturum bağlama olasılığı nedeniyle yalnızca sess->user = NULL yapmanın yeterli olmadığını yakaladı
  • True positive / false positive oranının çok yüksek olmaması nedeniyle tüm raporların yeterince dikkatli incelenip incelenmediği konusunda bir sınırlama bulunuyor

Zafiyet araştırmalarındaki pratik konumu

  • LLM'ler yaratıcılık, esneklik ve genellik açısından klasik program analizi tekniklerinden çok insan kod denetçilerine daha yakın bir yerde duruyor
  • Karşılaştırma için symbolic execution, abstract interpretation ve fuzzing anılıyor
  • GPT-4 sonrasında LLM'lerin zafiyet araştırmasında kullanılabileceği düşünülse de gerçek problemlerde sonuçlar beklendiği kadar güçlü değildi
  • o3; kod üzerinde akıl yürütme, soru-cevap, programlama ve problem çözmede gerçek zafiyet araştırmacılarının performansını artırabilecek düzeyde çalışıyor
  • Hâlâ kusursuz değil ve kullanıcıyı hayal kırıklığına uğratabilecek anlamsız sonuçlar üretebiliyor
  • Değişen nokta, gerçek problemlere uygulamaya değecek kadar doğru sonuca ulaşma olasılığının ilk kez yeterince yükselmiş olması

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-25
Hacker News yorumları

  • Küçük bir ayrıntı ama yazarın proje düzenleme biçimi faydalı görünüyor. Sistem prompt’unu, arka plan bilgisini ve yardımcı talimatları ayrı ayrı .prompt dosyaları olarak oluşturup [1], llm ile çalıştırma yöntemi
    İyi LLM kullanımının da diğer mühendislik araçları gibi sistemli olması gerektiğini; tasarım kısıtlarını dengeli biçimde yansıtan, iyi düşünülmüş şartname odaklı bir mühendislik düşüncesi gerektirdiğini gösteriyor
    [1] https://github.com/SeanHeelan/o3_finds_cve-2025-37899

    • Bunu böyle yorumlamak ilginç; çünkü yazar tam da o kısmı sezgisel yaptığını kabul ediyor

      In fact my entire system prompt is speculative so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering

    • Bu farklı metodolojileri nasıl benchmark etmek gerekir, bilmiyorum
      Hepsi sezgiye dayalı büyüler gibi görünüyor. “Siz bir zafiyet bulma uzmanısınız”, “Yanlış pozitif olmadan yalnızca gerçek zafiyetleri raporlayın” gibi ifadeler ya da model nedense hoşlanıyor gibi geldiği için sahte HTML etiketleriyle düzenleme yöntemleri. Burada mühendislik nerede, anlayamıyorum
    • Özünde istikrarsız ve öngörülemez bir sisteme mühendislik ilkeleri uygulayarak kontrol hissi elde etmeye çalışılması ilginç
      Böyle prompt’lara talimat değil, ipucu demek gerekir. Günümüzdeki tüm LLM’ler, prompt kendi tek üst hedefiyle — doğru olsun olmasın bir cevap üretmekle — çatıştığında prompt’u yok sayıyor
    • İlginç olan şu ki, LLM’e prompt yapılandırma en iyi uygulamalarını sorarsanız bu yönde ipuçları veriyor
      LLM’den prompt yazımında yardım istemek de şaşırtıcı derecede etkili. Benim prompt parçalarımın tamamı da LLM yardımıyla tasarlandı
      Şahsen hepsini org-mode dosyalarına koyuyorum ve gerektiğinde ChatGPT sohbetine kopyalayıp yapıştırıyorum. Daha “tartışma tarzı” etkileşimleri tercih ediyorum ama yaklaşım aynı
    • Sonuçta mesele düzen ve tertip: https://taoofmac.com/space/blog/2025/05/13/2230

  • Yazıda sinyal-gürültü oranının kabaca 1:50 olduğu söyleniyor. Yazar bu codebase’i çok iyi bildiği için gürültü içindeki sinyali seçmek açısından iyi bir konumda
    Asıl kazanım bu kısmı otomatikleştirmekte çıkacak, bu yüzden izlemeye devam edeceğim

    • Birkaç yıl boyunca birkaç take-home mülakat sorusu hazırladım; deneyimli geliştiriciler için kısa ve kolay, ama dili bilmiyorsanız zor olacak şekilde tasarladım. Hepsi gerçek işte çözdüğüm sorunların en küçük hâle indirgenmiş versiyonlarıydı
      Her yeni frontier LLM çıktığında, girdileri eğitim verisi olarak kullanan modeller hariç, bu mülakat sorularını çalıştırıyorum. İlk denemede çalışan yanıt oranının sürekli 1:10 civarında kalmasına ve kendi hatasını buldurmak için çoğu zaman 10 turdan fazla dürtmek gerekmesine şaşırdım
      Bu yüzden daha çetrefilli konularda bu seviyede bir sinyal-gürültü oranı makul geliyor
    • Hata tespitinde sinyal-gürültü oranını büyük ölçüde artıran bir sistem geliştiriyorum; aynı zamanda bilinen yazılım ajanlarını genel olarak sıkı şekilde benchmark ettim
      Sonuç aralığı epey genişti ve yakında yapılacak konferans sunumunda hepsini açıklayacağım, beklemeye değer. Bu alanın mevcut durumunu oldukça iyi gösterecek
      Düzenleme: ifade kafa karıştırıcıydı
    • Geçenlerde düşündüm: Linux çekirdeğinin tüm git değişiklikleri, mailing listeleri vb. üzerinde fine-tuning gibi bir şey yapmak mümkün olabilir mi diye
      Böyle bir LLM, yıllarca codebase üzerinde çalışıp her türlü özelliğini öğrenmiş bir insanın sentetik bir versiyonu gibi olmaz mı
      Uzun bağlama gerçekten çok şey sığdırılabiliyor, ama bazı codebase’ler yalnızca kod olarak bile şimdiden 200 bin token ediyor, o yüzden emin değilim
    • Bu kısmın otomasyonu basit gibi görünüyor. Genel olarak bir işi yapmaya yönelik anlamsal becerisi X olan bir LLM’in, aynı iş için verilmiş N yanıt arasından hangisinin en iyi olduğunu anlama becerisi X’ten daha yüksektir
      Özellikle birkaç hafta önce burada paylaşılan RAInk gibi ikili turnuva yöntemiyle bu daha da geçerli; farklı LLM’ler arası mutabakatı kullanma yöntemi de var. Burada Gemini 2.5 PRO kullanılmaması şaşırtıcı; benim deneyimime göre bu tür işler için en güçlü LLM o
    • 1:50, samanlıkta iğne aramak için harika bir tespit oranı

  • Bu yazıdaki en ilginç ve önemli kısım, yazarın her model için zafiyet aramasını 100 kez çalıştırmış olmasıydı
    Şimdiye kadar büyük dil modelleriyle denediğim çoğu problem için harcamayı düşündüğüm hesaplama miktarından çok daha fazla; ama belki de modeli sadece tekrar tekrar çalıştırmak gerekiyordur

    • Yazıya koymadığımı fark ettim; merak ediyorsanız 100 bin token’lık versiyonu 100 kez çalıştırmak yaklaşık 116 dolar tuttu
    • Sıfır gün açıkları büyük paraya satılabilir; bug bounty’ye gitse de para eder. LLM maliyeti bunun yanında kovada bir damla kalır
      Çıkarım maliyeti neredeyse sıfıra yaklaşınca siber güvenlik dünyasının ne olacağını bilmiyorum, ama bugünkünden çok farklı bir alan olacak
    • Yeterince paran varsa yeter~
    • “Model başına 100 kez” ciddi miktarda enerji tüketimi demek. C tabanlı codebase’lerde en yaygın zafiyeti bulmuş olması da başarıyı daha az etkileyici gösteriyor
      Daha çok lüksü ve israfı kutlamaya benziyor. Küresel iklim değişikliğiyle karşı karşıyayız ama hâlâ 1950’lerdeymiş gibi önemsiz işler için kaynak yakmaya devam ediyoruz

  • Ya çok şanslıydı ya da tahmin edildiği gibi Gemini 2.5 PRO bu zafiyeti daha kolay buluyor gibi. Başarı oranı yüksekti; şu prompt’u birkaç kez çalıştırmak yeterli oldu: https://gist.github.com/antirez/8b76cd9abf29f1902d46b2aed3cd...

  • Son dönemde bu kalıp sürekli tekrarlanıyor
    Net bir tanımı ve değerlendirme fonksiyonu olan bir problem varsa, LLM’in çözüm uzayını daraltmasını sağlıyoruz. LLM’ler örüntüleri yeniden kurmada çok güçlü ve cevap, önceden bilinenlere benzer bir örüntüdeyse iyi çalışabiliyor
    Bu durumda problem belirli bir güvenlik açığı türü, değerlendirici de bir uzman. Ölçek farklı olsa da, LLM’leri genetik optimizasyon için kullanmaya yönelik son denemelerle düşünce olarak benzer
    “Mathematical discoveries from program search with large language models” da ilginç bir okuma; hatırladığım kadarıyla daha önce HN’de de yer almıştı
    https://www.nature.com/articles/s41586-023-06924-6
    Ancak yalnızca bu deneye dayanarak LLM’in kod hakkında akıl yürüttüğü sonucuna varmak bana kişisel olarak biraz zorlama geliyor

  • Bunun gerçek olmasını ve curl’de sürekli yaşananlarla aynı şey olmamasını umuyorum
    [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

  • Bunun LLM ile bulunan ilk güvenlik açığı olduğu iddiasından emin değilim. Örneğin OSS-Fuzz [0], fuzzing ile birkaç tane buldu; Big Sleep de ajan yaklaşımıyla buldu [1]
    [0] https://security.googleblog.com/2024/11/leveling-up-fuzzing-...
    [1] https://googleprojectzero.blogspot.com/2024/10/from-naptime-...

    • LLM ile bulunan ilk güvenlik açığı kesinlikle değil =) Belki daha açık yazmalıydım
      Yazıda söylediğim şey şuydu: “Güvenlik açığını anlamak için sunucuya eşzamanlı bağlantıları ve belirli durumlarda birden çok nesnenin nasıl paylaşıldığını akıl yürütmek gerekiyor. o3 bunu anladı ve referans sayımı yapılmayan belirli bir nesnenin, başka bir iş parçacığında hâlâ erişilebilir durumdayken serbest bırakıldığı yeri buldu. Bildiğim kadarıyla, bu nitelikteki bir güvenlik açığını bir LLM’in bulduğuna dair ilk açık tartışma bu”
      Söylemek istediğim, bildiğim kadarıyla bir LLM’in bu türden bir hatayı, yani azımsanmayacak miktarda koddan ve paylaşılan kaynaklara eşzamanlı erişimden kaynaklanan bir hatayı bulduğuna dair kamuya açık ilk belgeleme olduğuydu. En azından benim için LLM gelişiminde ilginç bir işaret

  • Sıfır gün bulmanın değeri düşünüldüğünde, yalnızca birkaç yüz API çağrısıyla güvenilir biçimde bulunabiliyorsa dünyadaki neredeyse tüm istihbarat kurumları buna para akıtır
    Özellikle model çok sayıda örnekle ince ayar yapılabiliyorsa; OpenAI gibi yerlerin bunu herkese açık API üzerinden sunacağını da sanmıyorum

    • Doğru. Çıktı denetimi, yani sansür etrafındaki mühendislik ve kullanım koşulları nedeniyle, olası hataları bulmaya yönlendirip sonuçta buna izin vermeme yönünde bir motivasyon oluşuyor
      Devlet kurumları veya başka kuruluşlar için bu kısıtlar doğal olarak sorun olmaz. Yalnızca geri kalan herkese uygulanır. Bu yüzden insanlar bu sınırlamaların olmadığı başka modeller ve ajanlar kullanacak
      Kritik yazılımların pek çok yerinde çok sayıda güvenlik açığı bulunduğunu varsaymak güvenli. Artık bunları bulabilir hâle geldik. Bilgisayar güvenliği ve hackleme alanında silahlanma yarışı oyun teorisinin geçerli olduğu bir durum başlayacak. Muhtemelen beklenenden daha erken gelebilir

  • Birkaç çekirdek geliştiricisinin bu hatayı “doğruladığını” anlıyorum, ama gerçekten kavram kanıtı oluşturup test eden biri olup olmadığını merak ediyorum
    Sürecin bu kadar temel bir parçası olmasına rağmen kavram kanıtı tamamen eksik. Kavram kanıtı yoksa ortada ne tür bir sorun çıkacağını bilemezsiniz; dolayısıyla istismar edilebilirliği veya etkisini değerlendiremezsiniz. En azından yazar bunu doğrulama olmadan uzaktan kod çalıştırma diye adlandırmamış
    Ama ya yazarın ve geliştiricilerin gözden kaçırdığı ya da o3’ün ele aldığını varsaydıkları fakat aslında o3’ün bağlamının dışında kalan bir yapboz parçası varsa ve bu, güvenlik açığının kendisini geçersiz kılıyorsa?
    Böyle bir şey olduğunu söylemiyorum, yazarın işini onun yerine yapmak için zaman ayıracağımı da söylemiyorum. Sadece bu raporun tam olarak doğrulanmış olmadığını ve ileride LLM güvenlik açığı araştırmaları alanında etkili bir blog yazısı olma ihtimali düşünüldüğünde tehlikeli bir emsal gibi hissettirdiğini söylüyorum
    Kişisel olarak, modelin ürettiği herhangi bir güvenlik açığı raporuna PoC || GTFO ilkesinin her zamankinden daha sıkı uygulanması gerektiğini düşünüyorum
    o3’ün önceki modellerden veya mevcut diğer modellerden çok daha iyi olduğu görüşü hâlâ geçerli; yöntem de ilginç. İnsanların belirli bir şeye dikkatini çekmek için ifadeyi böyle kurma isteğini ve ihtiyacını anlıyorum. Clickbait sorunu da bu. Ama lütfen daha iyisini yapalım. Kavram kanıtı oluşturup iddiaları doğrulamak gerekir; tembel davranmamak gerekir. Güvenlik açığı araştırmacılarının araştırma yöntemlerini etkileyebilecek bir blog yazısı yazıyorsanız, teorik varsayımları değil doğrulamayı teşvik etmelisiniz. Aksi hâlde, doğrulanabilir ve kanıtlanmış raporlarla sistem anlayışını derinleştirmek yerine, yanlış ama inandırıcı raporlar cehaleti yayar

    • Yazarıyım. Evet, kavram kanıtı oluşturdum. Evet, KASAN raporu ve çökme tetikledim
    • use-after-free ile çökme tetikleyen bir kavram kanıtı mı istiyorsunuz, yoksa yalnızca eksiksiz bir uzaktan kod çalıştırma kavram kanıtıyla mı tatmin olacaksınız, bunu sormak isterim

  • Çoğu prompt geliştirme oturumumun nasıl geçtiğini mükemmel yakalayan, güzel ve küçük bir pasaj var

    I tried to strongly guide it to not report false positives, and to favour not reporting any bugs over reporting false positives. I have no idea if this helps, but I’d like it to help, so here we are. In fact my entire system prompt is speculative in that I haven’t ran a sufficient number of evaluations to determine if it helps or hinders, so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering. Once I have ran those evaluations I’ll let you know.