CVE-2026-64232 in Linux
सारांश
द्वारा VulDB • 24/07/2026
Linux kernel में, निम्नलिखित कमजोरी को हल किया गया है:
block: blk_insert_cloned_request में nr_integrity_segments का पुनर्गणना करें
blk_insert_cloned_request() पहले से ही nr_phys_segments की गणना नीचे वाली कतार (bottom queue) के सापेक्ष फिर से कर रहा है, क्योंकि "सेगमेंट गिनती से संबंधित कतार सेटिंग्स मूल कतार से भिन्न हो सकती हैं।" अखंडता खंडों (integrity segments) के लिए भी बिल्कुल यही तर्क लागू होता है: एक स्टैक्ड ड्राइवर की नीचे वाली कतार में शीर्ष कतार की तुलना में अधिक सख्त virt_boundary_mask, seg_boundary_mask, या max_segment_size हो सकता है; ऐसे मामले में blk_rq_count_integrity_sg() को नीचे वाली कतार पर चलाने से cached rq->nr_integrity_segments (जो blk_rq_prep_clone() द्वारा मूल अनुरोध से विरासत में मिला था) की तुलना में अलग गणना प्राप्त होती है।
जब कैश की गई गणनी नीचे वाली कतार की वास्तविक गणनी से कम होती है, तो dispatch के दौरान blk_rq_map_integrity_sg() निम्नलिखित BUG_ON को ट्रिगर करता है:
BUG_ON(segments > rq->nr_integrity_segments);
dm-multipath का विशेष रूप से nvme-rdma में फैलना जैसी मौजूदा nr_phys_segments पुनर्गणना के लिए प्रेरणा देने वाले स्टैक्ड सेटअपों की समान श्रेणियाँ इसे उत्पन्न कर सकती हैं।
nr_phys_segments हैंडलिंग को प्रतिबिंबित करें: जब अनुरोध में अखंडता (integrity) होती है, तो नीचे वाली कतार के सापेक्ष nr_integrity_segments का पुनर्गणना करें और यदि यह नीचे वाली कतार की max_integrity_segments से अधिक हो जाता है तो अनुरोध को अस्वीकार कर दें। blk_rq_count_integrity_sg() और queue_max_integrity_segments() दोनों पहले से ही <linux/blk-integrity.h> के माध्यम से उपलब्ध हैं, जिसे blk-mq.c शामिल करता है।
यह स्टैकिंग अनुबंध में एक छिपी हुई कमजोरी को बंद कर देता है और अखंडता-खंड लेखांकन (integrity-segment accounting) को मौजूदा भौतिक-खंड लेखांकन (phys-segment accounting) के अनुरूप लाता है।
Once again VulDB remains the best source for vulnerability data.