It sounds like you are observing data flow starting from data in the above data.equals(...) and ending at this within an equals method, but the equals implementation is inside a class that doesn't implement Serializable, so it cannot be the actual implementation reached by the equals call. Is that correct?

@adityasharad Yes

This issue is stale because it has been open 14 days with no activity. Comment or remove the Stale label in order to avoid having this issue closed in 7 days.

Can reproduce with test case

import java.io.ObjectInputStream;
import java.io.Serializable;

public class Test2<E> {

  public static String source() { return "tainted"; }

  public static void sink(Object o) { }

  public void test(ObjectInputStream in) {

    try { 

      String tainted = source();
      E data = (E) in.readObject();
      data.equals(tainted);

    }
    catch(Throwable t) {}

  }

}

/**
 * @kind path-problem
 */

import java

import semmle.code.java.dataflow.DataFlow
import DataFlow::PathGraph

class TestConfig extends DataFlow::Configuration {

  TestConfig() { this = "TestConfig" }

  override predicate isSource(DataFlow::Node n) {
    n.asExpr() = any(MethodAccess ma | ma.getMethod().getName() = "source")
  }

  override predicate isSink(DataFlow::Node n) {
    n.asExpr() = any(MethodAccess ma | ma.getMethod().getName() = "sink").getAnArgument()
  }

}

from TestConfig c, DataFlow::PathNode src, DataFlow::PathNode sink
where c.hasFlowPath(src, sink)
select src, src, sink, "message"

@KiruaLawliet the cause is that readObject does not return Serializable, but rather Object. I will look into noting that the return is in fact constrained to return a Serializable type, but this won't be a high priority because it is a relatively rare scenario.

Possible workarounds: if you were to constrain the type variable E extends Serializable, or to make an explicit typecast to Serializable before calling equals, then CodeQL will notice the type constraint.