All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Namjae Jeon <linkinjeon@kernel.org>,
	Ziyan Xu <research@securitygossip.com>,
	Steve French <stfrench@microsoft.com>,
	Sasha Levin <sashal@kernel.org>,
	smfrench@gmail.com, linux-cifs@vger.kernel.org
Subject: [PATCH AUTOSEL 6.15 09/15] ksmbd: fix potential use-after-free in oplock/lease break ack
Date: Mon, 14 Jul 2025 19:06:10 -0400	[thread overview]
Message-ID: <20250714230616.3709521-9-sashal@kernel.org> (raw)
In-Reply-To: <20250714230616.3709521-1-sashal@kernel.org>

From: Namjae Jeon <linkinjeon@kernel.org>

[ Upstream commit 50f930db22365738d9387c974416f38a06e8057e ]

If ksmbd_iov_pin_rsp return error, use-after-free can happen by
accessing opinfo->state and opinfo_put and ksmbd_fd_put could
called twice.

Reported-by: Ziyan Xu <research@securitygossip.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

**YES**

This commit should be backported to stable kernel trees. Here's my
extensive analysis:

## Security Impact Analysis

This commit fixes a critical **use-after-free vulnerability** in the
oplock/lease break acknowledgment handling code paths in ksmbd (kernel
SMB server). This is a serious security issue that can lead to:

1. **Memory corruption** - Accessing freed memory can corrupt kernel
   memory
2. **Kernel crashes** - Dereferencing freed pointers can cause kernel
   panics
3. **Potential privilege escalation** - UAF vulnerabilities can
   potentially be exploited for privilege escalation

## Code Analysis

The commit addresses a race condition where:

1. **Double-free issue**: Both `opinfo_put()` and `ksmbd_fd_put()` could
   be called twice on error paths
2. **Use-after-free of opinfo->op_state**: The code was accessing
   `opinfo->op_state` after potentially freeing the opinfo structure

### Specific Code Changes

In both `smb20_oplock_break_ack()` and `smb21_lease_break_ack()`, the
fix reorganizes the cleanup logic:

**Before (vulnerable pattern):**
```c
opinfo->op_state = OPLOCK_STATE_NONE;
wake_up_interruptible_all(&opinfo->oplock_q);
opinfo_put(opinfo);
ksmbd_fd_put(work, fp);

// ... response setup ...
ret = ksmbd_iov_pin_rsp(work, rsp, sizeof(...));
if (!ret)
    return;

err_out:
opinfo->op_state = OPLOCK_STATE_NONE;  // UAF: opinfo may be freed
wake_up_interruptible_all(&opinfo->oplock_q);
opinfo_put(opinfo);  // Double-free
ksmbd_fd_put(work, fp);  // Double-free
```

**After (fixed pattern):**
```c
// ... response setup ...
ret = ksmbd_iov_pin_rsp(work, rsp, sizeof(...));
if (ret) {
err_out:
    smb2_set_err_rsp(work);
}

// Single cleanup path
opinfo->op_state = OPLOCK_STATE_NONE;
wake_up_interruptible_all(&opinfo->oplock_q);
opinfo_put(opinfo);
ksmbd_fd_put(work, fp);
```

## Stable Kernel Criteria

This commit meets all the stable kernel requirements:

1. **Fixes a real bug**: UAF vulnerabilities are serious security bugs
2. **Small and contained**: The fix is minimal, only reorganizing
   cleanup logic
3. **No new features**: Only fixes the bug, no functional changes
4. **Low regression risk**: The change is straightforward and doesn't
   modify core logic
5. **Clear fix**: The commit clearly addresses the specific UAF issue

## Historical Context

Looking at similar commits in ksmbd:
- Multiple UAF fixes have been backported (e.g., commits 18b4fac5ef17,
  21a4e47578d4, a1f46c99d9ea)
- All have "Cc: stable@vger.kernel.org" tags
- This follows the same pattern of fixing race conditions and UAF issues
  in SMB protocol handling

## Conclusion

This commit should be backported because:
1. It fixes a critical security vulnerability (UAF)
2. The fix is minimal and low-risk
3. It follows the pattern of other ksmbd UAF fixes that were backported
4. The vulnerability was reported by a security researcher (Ziyan Xu)
5. It prevents potential kernel crashes and exploitation

The commit follows stable tree rules perfectly - it's a targeted fix for
an important bug with minimal changes and no architectural
modifications.

 fs/smb/server/smb2pdu.c | 29 +++++++++--------------------
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index ad2b15ec3b561..f1c7ed1a6ca59 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -8535,11 +8535,6 @@ static void smb20_oplock_break_ack(struct ksmbd_work *work)
 		goto err_out;
 	}
 
-	opinfo->op_state = OPLOCK_STATE_NONE;
-	wake_up_interruptible_all(&opinfo->oplock_q);
-	opinfo_put(opinfo);
-	ksmbd_fd_put(work, fp);
-
 	rsp->StructureSize = cpu_to_le16(24);
 	rsp->OplockLevel = rsp_oplevel;
 	rsp->Reserved = 0;
@@ -8547,16 +8542,15 @@ static void smb20_oplock_break_ack(struct ksmbd_work *work)
 	rsp->VolatileFid = volatile_id;
 	rsp->PersistentFid = persistent_id;
 	ret = ksmbd_iov_pin_rsp(work, rsp, sizeof(struct smb2_oplock_break));
-	if (!ret)
-		return;
-
+	if (ret) {
 err_out:
+		smb2_set_err_rsp(work);
+	}
+
 	opinfo->op_state = OPLOCK_STATE_NONE;
 	wake_up_interruptible_all(&opinfo->oplock_q);
-
 	opinfo_put(opinfo);
 	ksmbd_fd_put(work, fp);
-	smb2_set_err_rsp(work);
 }
 
 static int check_lease_state(struct lease *lease, __le32 req_state)
@@ -8686,11 +8680,6 @@ static void smb21_lease_break_ack(struct ksmbd_work *work)
 	}
 
 	lease_state = lease->state;
-	opinfo->op_state = OPLOCK_STATE_NONE;
-	wake_up_interruptible_all(&opinfo->oplock_q);
-	atomic_dec(&opinfo->breaking_cnt);
-	wake_up_interruptible_all(&opinfo->oplock_brk);
-	opinfo_put(opinfo);
 
 	rsp->StructureSize = cpu_to_le16(36);
 	rsp->Reserved = 0;
@@ -8699,16 +8688,16 @@ static void smb21_lease_break_ack(struct ksmbd_work *work)
 	rsp->LeaseState = lease_state;
 	rsp->LeaseDuration = 0;
 	ret = ksmbd_iov_pin_rsp(work, rsp, sizeof(struct smb2_lease_ack));
-	if (!ret)
-		return;
-
+	if (ret) {
 err_out:
+		smb2_set_err_rsp(work);
+	}
+
+	opinfo->op_state = OPLOCK_STATE_NONE;
 	wake_up_interruptible_all(&opinfo->oplock_q);
 	atomic_dec(&opinfo->breaking_cnt);
 	wake_up_interruptible_all(&opinfo->oplock_brk);
-
 	opinfo_put(opinfo);
-	smb2_set_err_rsp(work);
 }
 
 /**
-- 
2.39.5


  parent reply	other threads:[~2025-07-14 23:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-14 23:06 [PATCH AUTOSEL 6.15 01/15] wifi: mac80211: always initialize sdata::key_list Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 02/15] net/sched: sch_qfq: Fix null-deref in agg_dequeue Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 03/15] erofs: allow readdir() to be interrupted Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 04/15] rxrpc: Fix oops due to non-existence of prealloc backlog struct Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 05/15] net: thunderx: avoid direct MTU assignment after WRITE_ONCE() Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 06/15] eventpoll: don't decrement ep refcount while still holding the ep mutex Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 07/15] gpio: of: initialize local variable passed to the .of_xlate() callback Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 08/15] perf/core: Fix WARN in perf_sigtrap() Sasha Levin
2025-07-14 23:06 ` Sasha Levin [this message]
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 10/15] wifi: mt76: fix queue assignment for deauth packets Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 11/15] wifi: mt76: add a wrapper for wcid access with validation Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 12/15] wifi: mac80211: clear frame buffer to never leak stack Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 13/15] pinctrl: aw9523: fix can_sleep flag for GPIO chip Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 14/15] ALSA: hda/realtek: Add quirk for ASUS ExpertBook B9403CVAR Sasha Levin
2025-07-14 23:06 ` [PATCH AUTOSEL 6.15 15/15] ASoC: Intel: sof_sdw: Add quirks for Lenovo P1 and P16 Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250714230616.3709521-9-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=linkinjeon@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=research@securitygossip.com \
    --cc=smfrench@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=stfrench@microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.