Skip to content

Possible deadlock in jail implementation #22

Description

@david-garcia-garcia

Please consider this premise (which might be wrong);

If the mutex is read locked, a call to Lock is blocked**. If one or more readers hold a lock, you cannot write.

And this is where de deadlock could happen:

func (a *Modsecurity) ServeHTTP(rw http.ResponseWriter, req *http.Request) {	

       [...]

       if a.jailEnabled {
		a.jailMutex.RLock()
		if a.isClientInJail(clientIP) {
			a.jailMutex.RUnlock()
                        [...]
			return
		}
		a.jailMutex.RUnlock()
	}

isClientInJail has a call to releaseFromJail

  func (a *Modsecurity) releaseFromJail(clientIP string) {
  	a.jailMutex.Lock()
  	defer a.jailMutex.Unlock()
  
  	delete(a.jail, clientIP)
  	delete(a.jailRelease, clientIP)
  	a.logger.Printf("client %s released from jail", clientIP)
  }

Here jailMutex.Lock() will be stuck forever as a previously unreleased read lock was obtained in the main ServeHTTP.

I'll investigate further to confirm/reproduce.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions