[Feature Request] support add constraint on typeVariable while perform virtual dispatch in java query

[KiruaLawliet]

Is it possible to add class type constraint on TypeVariable while perform virtual dispatch in java query？

Take this sinppet for example：

E data = (E) in.readObject();
data.equals(....);

It seems data can be any class and have data flow tracked into equals method as long as the class has one even if the class is unserializable.

[adityasharad]

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?

[KiruaLawliet]

@adityasharad Yes

[github-actions]

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.

[smowton]

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"

[smowton]

@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.