-
Notifications
You must be signed in to change notification settings - Fork 12
[LTS 8.6] cifs: CVE-2023-53751 #1059
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: ciqlts8_6
Are you sure you want to change the base?
Changes from all commits
c746f8a
601cd8f
9d7bba3
ac27ef5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -1123,8 +1123,10 @@ int match_target_ip(struct TCP_Server_Info *server, | |||||||||||
| goto out; | ||||||||||||
| } | ||||||||||||
|
|
||||||||||||
| spin_lock(&cifs_tcp_ses_lock); | ||||||||||||
| *result = cifs_match_ipaddr((struct sockaddr *)&server->dstaddr, | ||||||||||||
| &tipaddr); | ||||||||||||
| spin_unlock(&cifs_tcp_ses_lock); | ||||||||||||
|
Comment on lines
+1126
to
+1129
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
cifs_server_lock(server);
#ifdef CONFIG_CIFS_SWN_UPCALL
if (server->use_swn_dstaddr) {
server->dstaddr = server->swn_dstaddr;
} else {
#endif
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The kernel-src-tree/fs/cifs/connect.c Lines 116 to 119 in ac27ef5
and its call in kernel-src-tree/fs/cifs/connect.c Line 336 in ac27ef5
The usage you highlighted is not compiled into Even if
The last option was chosen as making the most sense, but it should be treated as a bonus, certainly not as a prompt for scratching the whole solution which wasn't even concerned with protecting
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see, the CVE itself only cares about
When we diverge from upstream, we need to make sure that our own solutions won't create an unfixable conflict for future CVE fixes. And we should be prudent that our divergence won't create a snowball of extra work for every subsequent fix too. If you look through the outstanding CIFS-related CVEs that need to be fixed in 8.6 and none of them seem like they'll create a big headache due to this PR, then we can move forward with the approach in this PR. But if it seems like there's a big CIFS headache waiting for us that could've been avoided by biting the bullet now and backporting the big locking overhaul, then we should scratch this solution and do just that. CC @PlaidCat if you have some thoughts here.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Sorry, I do not have this knowledge, I'm only handled CVEs to fix a few at the time.
It's not my decision to make and I don't have much useful input on that matter either, so I'll refrain from suggesting anything. If CIQ decides to go that way then I can backport this locking overhaul and rework this PR to suit it. It's not like much effort will be discarded, maybe 25%. However, there may be a lot of additional effort needed to backport d7d7a66. Certainly not less than this PR, no idea about the upper bound though. Doing a quick ch-p I can see 13 files modified and conflicts in every single one of them. Also it's all locks, which must be approached very carefully.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My stance from this was that @pvts-mat looked at the CVE and attempted to address the missing protections on This is the joy of managing an LTS, its not ideal for correctness to upstream state but its the hand we're dealt. I think we went above and beyond to address the problem holistically to the original intent of the CVE. We have also ran into this problem when the upstream injects fixes with features, There are a total of 3 outstanding CVEs and 2 of them below our official support level. We also have the problem of can we even rebase the subsystem (is that viable). The other outstanding CVEs are for In addition this commit called out wasn't clean anyways and was added late into the 8.10 process It also looks like there is a huge number of changes since this LTS forked as well. |
||||||||||||
| cifs_dbg(FYI, "%s: ip addresses match: %u\n", __func__, *result); | ||||||||||||
| rc = 0; | ||||||||||||
|
|
||||||||||||
|
|
||||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cifs_set_port((struct sockaddr *)&server->dstaddr, CIFS_PORT);modifiesserver->dstaddrwithout any lock held. This was fixed in the large upstream rework commit 665e187 ("cifs: Improve handling of NetBIOS packets").That being said, there's a bigger problem with this commit:
cifs_find_tcp_session()readsserver->dstaddrfrommatch_server()without taking the server mutex lock. So the loop incifs_find_tcp_session()needs to take the server mutex lock, but wait: that loop's linked list traversal is protected by thecifs_tcp_ses_lockspin lock. So each server's mutex lock cannot be taken inside the loop, because it would sleep in atomic context:Upstream commit d7d7a66 ("cifs: avoid use of global locks for high contention data") is a mandatory prerequisite for this commit. That upstream commit also fixes the missing locking in
cifs_find_tcp_session()to protect theserver->dstaddraccess.I stopped reviewing this commit at that point, since it was clear that this needed to be reworked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It takes the
cifs_tcp_ses_lockspinlock which protects fromcifs_reconnect()writing as explained in #1059 (comment).Yes, this write is unprotected, and this time it does seem to be compiled into
ciqlts8_6, but - again - fixingdstaddrsynchronization issues is out of scope of CVE-2023-53751.Please continue. It's not clear at all unless it's decided to widen the scope of this PR beyond the CVE-2023-53751 fix, which AFAIK from @PlaidCat already got too large from the business perspective.