Wikipedia:Articles for deletion/SLUBStick

The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

The result was delete‎. ✗plicit 11:29, 17 January 2025 (UTC)[reply]

SLUBStick (edit | talk | history | protect | delete | links | watch | logs | views) – (View log | edits since nomination)

(Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL)

No indication of notability. Could be merged elsewhere. TheTechie@enwiki (she/they | talk) 19:51, 3 January 2025 (UTC)[reply]

• Note: This discussion has been included in the list of Computing-related deletion discussions. Shellwood (talk) 20:19, 3 January 2025 (UTC)[reply]
• Delete. I don't even know where this article could be merged. Linux kernel#Security does not seem like a good fit and there does not appear to be a Security of the Linux Kernel themed article. Brandon (talk) 17:01, 6 January 2025 (UTC)[reply]
• Keep Significant vulnerability that will very likely see further developments in the future. — Preceding unsigned comment added by Dujo (talk • contribs) on 2024-01-08 at 15:31:10 (UTC)

  That's a pretty bold claim. If this technique was being received as significant I'd expect to see _some_ response that just never materialized. The references are all just repackaging the researcher's press briefing. Is there any material from the Linux community, vendors or other academics? I was unable to find any. Brandon (talk) 18:04, 8 January 2025 (UTC)[reply]

  SLUBStick is not a security vulnerability in itself, it is a technique that makes exploitation of other vulnerabilities easier. There is an official response from the SUSE Linux vendor: https://www.suse.com/support/kb/doc/?id=000021529. Dujo (talk) 04:34, 9 January 2025 (UTC)[reply]

  Your argument makes no sense. Based on what you have provided, it may manifest to greater depths in the future. Alas, we can't keep articles on the bet that it will gain notability in the future. That'd be like if we created an article for Windows 13 betting that there would be a Windows 13 in the future (we don't know if there will be, and would be some pretty serious CRYSTALBALL violations). We only decide to keep or delete an article based on the current notability, not what we predict will be there in the future.
  
  

  As such, I don't think your vote is necessarily justified. Even if SUSE released something about it (as you mentioned in your comment), doesn't mean it is notable. Per GNG, we need reliable sources. A support article isn't really reliable.
  
  

  Why don't we analyze the sources, including the ones you added (based on this revision):
  
  

  1. "Linux kernel impacted by new SLUBStick cross-cache attack"

  • Reliability: medium to good
  • In-depth: yes
  • Independent: yes

  2. SUSE source

  • Reliability: ok; support article isn't the best given only a few sources
  • In-depth: no, just lists a brief about what it is and what to do to avert it, nothing more
  • Independent: interpretations vary. Independent of Linux? No. Independent of parties tied to the exploit? Yes?

  3. USENIX source

  • Reliability: I don't know here, it seems like a research paper so I'll say yes.
  • In-depth: heck yeah. It's a 19 page research paper.
  • Independent: Probably yes

  4. SecurityWeek source

  • Reliability: I might be wrong, but doesn't seem that well-established. So I'll say probably no.
  • In-depth: 2 paragraphs is less than enough to be in-depth/
  • Independent: yes

  
  For this article to pass GNG, you would generally need 3+ sources which pass all three criteria. None of the sources fully pass.
  

  
  Since this appears to only be your 3rd AFD, I recommend you put some thoughts into your votes before participating in your next AFD. Please also reconsider adding sources for the sake of an argument also, it never helps as you can see. TheTechie@enwiki (she/they | talk) 05:20, 9 January 2025 (UTC)[reply]

  Thank you for your answer. I agree with you that predicting the future with certainty is impossible. I joined this discussion after noticing the community portal link and thought it would be a good opportunity to collaborate. However, I soon encountered what I felt like a push to delete valuable pages and information, which compelled me to speak up in defense of others’ work and effort.

  That said, I do not wish to engage in sterile and endless debates between inclusionists and deletionists. Therefore, I’ve decided to take a break from contributing to Wikipedia while I look for a more welcoming and inclusive online community where I can invest my time and energy. Dujo (talk) 22:24, 9 January 2025 (UTC)[reply]

  I hope you understand that my comment was not intended to be a personal attack. I was just clarifying why you voted as keep. TheTechie@enwiki (she/they | talk) 05:34, 15 January 2025 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Beeblebrox ^Beebletalks 22:45, 10 January 2025 (UTC)[reply]

• Delete This should be up-merged somewhere, not sure where (maybe it is time to create Cross-cache attacks?). USENIX is a extremely reliable venue and I have no issues with the research paper, however, one research paper does not make a topic notable. Sohom (talk) 12:08, 14 January 2025 (UTC)[reply]

Delete: I couldn't find sufficient sourcing to establish notability. Note that the USENIX paper is authored by researchers who initially proposed the method. While they are reliable and in-depth, they cannot serve as an independent source. The other sources are largely summaries of the original paper and thus do little to establish notability. HyperAccelerated (talk) 06:16, 16 January 2025 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.