Skip to content

SEC-2980: Possible race condition in SessionRegistryImpl #3189

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

Closed
spring-projects-issues opened this issue May 18, 2015 · 1 comment
Closed
Assignees
Labels
in: core An issue in spring-security-core status: backported An issue that has been backported to maintenance branches type: bug A general bug type: jira An issue that was migrated from JIRA
Milestone

Comments

@spring-projects-issues
Copy link

Selene Feigl (Migrated from SEC-2980) said:

Hello,

there is a possible race condition in SessionRegistryImpl when handling the principals map (principal -> session id)

  • A principal P has one Session S1 in its set
  • Thread A wants to add S2 to the same principal (calling registerNewSession)
  • Thread A checks whether there is already a Set for principal P and gets a reference to the set containing S1
  • Thread B wants to remove S1 (calling removeSessionInformation)
  • Thread B obtains set from principal map and removes S1 from the Set
  • Thread B checks wheter the Set is empty - it is - as Thread A did not add S2 yet - and removes it from the Map
  • Thread A adds S2 to the non-referenced Set

Result: principals does not contain S2 as it should. If the session registry is used to limit number of sessions per user, the limit is not enforced. If a Spring application uses the SessionRegistry for other things, they won't work as expected. (listing all logged in users etc.)

@spring-projects-issues spring-projects-issues added in: core An issue in spring-security-core Open type: bug A general bug type: jira An issue that was migrated from JIRA labels Feb 5, 2016
@lrozenblyum
Copy link
Contributor

lrozenblyum commented Mar 28, 2019

To partially overcome this problem I wrapped it with a synchronized decorator as mentioned: #5775

@rwinch rwinch removed the Open label May 3, 2019
jeffrey-easyesi added a commit to jeffrey-easyesi/spring-security that referenced this issue Aug 2, 2019
Adding/removing sessions from principals wasn't atomic. If one thread
removed the last session from a principal while another thread added a
new one, the addition could be lost.
@rwinch rwinch self-assigned this Aug 6, 2019
@rwinch rwinch added this to the 5.2.0.RC1 milestone Aug 6, 2019
@rwinch rwinch closed this as completed in a17d664 Aug 6, 2019
rwinch pushed a commit that referenced this issue Aug 6, 2019
Adding/removing sessions from principals wasn't atomic. If one thread
removed the last session from a principal while another thread added a
new one, the addition could be lost.

Fixes gh-3189
@spring-projects-issues spring-projects-issues added the status: backported An issue that has been backported to maintenance branches label Aug 6, 2019
rwinch pushed a commit that referenced this issue Aug 6, 2019
Adding/removing sessions from principals wasn't atomic. If one thread
removed the last session from a principal while another thread added a
new one, the addition could be lost.

Fixes gh-3189
kostya05983 pushed a commit to kostya05983/spring-security that referenced this issue Aug 26, 2019
Adding/removing sessions from principals wasn't atomic. If one thread
removed the last session from a principal while another thread added a
new one, the addition could be lost.

Fixes spring-projectsgh-3189
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core An issue in spring-security-core status: backported An issue that has been backported to maintenance branches type: bug A general bug type: jira An issue that was migrated from JIRA
Projects
None yet
Development

No branches or pull requests

3 participants