CVE-2024-40952 in Linux
요약
\~에 의해 VulDB • 2026. 06. 17.
리포트된 스택 트레이스는 OCFS2 파일 시스템에서 `ocfs2_reflink_remap_blocks` 함수 호출 중 발생한 크래시를 보여줍니다. 이는 `ioctl_file_clone` (또는 `copy_file_range`)를 통해 파일 클론링(리플링크) 작업을 수행할 때, 하위 레벨에서 트랜잭션 또는 저널 처리 중 오류가 발생하여 시스템이 패닉으로 이어졌음을 시사합니다.
제시된 해결책은 `ocfs2_journal_dirty()` 함수 내에서 오류 처리 로직을 수정하여, 즉시 `ocfs2_abort()`를 호출하여 전체 파일 시스템을 중단시키는 대신, **현재 트랜잭션과 저널만 중단(abort)시키고, 이후 트랜잭션 시작 시점에서 `ocfs2_abort()`를 호출하도록 지연시키는 것**입니다. 또한, 이 경우 핸들(handle)의 상세 정보를 로깅하여 디버깅을 용이하게 합니다.
이 변경은 다음과 같은 이점을 가집니다: 1. **즉각적인 시스템 패닉 방지**: 오류 발생 시 즉시 전체 파일 시스템을 마비시키지 않고, 현재 작업만 중단시킵니다. 2. **더 나은 오류 격리**: 오류가 발생한 특정 트랜잭션만 영향을 받고, 다른 트랜잭션은 정상적으로 처리될 수 있는 여지를 남깁니다. 3. **디버깅 용이성**: 핸들 정보를 로깅함으로써 오류의 원인을 더 쉽게 추적할 수 있습니다.
### 수정된 코드 예시 (개념적)
```c // ocfs2_journal_dirty() 함수 내 수정 사항
int ocfs2_journal_dirty(handle_t *handle, struct buffer_head *bh) {
int ret;
// 기존 로직...
if (ret) {
// 기존: ocfs2_abort(handle->h_transaction->t_fs, ret); // 새로운 로직: 현재 트랜잭션과 저널만 중단 ocfs2_journal_abort(handle->h_transaction, ret); // 핸들 상세 정보 로깅 mlog(ML_ERROR, "Journal dirty failed for handle: " "trans_id=%u, block=%lu, error=%d\n", handle->h_transaction->t_tid, bh->b_blocknr, ret); // 이후 트랜잭션 시작 시 ocfs2_abort()가 호출되도록 플래그 설정 // 예: handle->h_transaction->t_flags |= OCFS2_TRANS_ABORTED; return ret; }
// 나머지 로직... }
// ocfs2_start_trans() 또는 유사한 트랜잭션 시작 함수 내 수정 사항 int ocfs2_start_trans(struct ocfs2_super *osb, int credits) {
struct ocfs2_journal *journal = osb->journal; int ret;
// 기존: 트랜잭션 시작 로직...
// 새로운 로직: 이전에 중단된 트랜잭션이 있었는지 확인 if (journal->j_flags & OCFS2_JOURNAL_ABORTED) {
mlog(ML_ERROR, "Aborting filesystem due to previous journal error\n"); ocfs2_abort(osb, -EIO); // 이제 여기서 전체 파일 시스템 중단 return -EIO; }
// 기존 로직 계속... } ```
### 요약
이 수정은 `ocfs2_journal_dirty()`에서 오류 발생 시 즉시 `ocfs2_abort()`를 호출하는 대신, 현재 트랜잭션과 저널만 중단시키고, 이후 트랜잭션 시작 시점에서 전체 파일 시스템 중단(`ocfs2_abort()`)을 수행하도록 변경합니다. 또한, 오류 발생 시 핸들 정보를 로깅하여 디버깅을 용이하게 합니다. 이는 시스템의 안정성을 높이고, 오류의 원인을 더 쉽게 추적할 수 있도록 합니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.