Use after free in propagator_state.cc
cc @mihaimaruseac 

Code where `next_iter` is initialized and used:
https://github.com/tensorflow/tensorflow/blob/6f692f73cb2043b4a0b0446539cd8c15b3dd9220/tensorflow/core/common_runtime/propagator_state.cc#L755-L772

`ActivateLoopInvs`:
https://github.com/tensorflow/tensorflow/blob/6f692f73cb2043b4a0b0446539cd8c15b3dd9220/tensorflow/core/common_runtime/propagator_state.cc#L701-L715

`AdjustOutstandingOpsLocked`:
https://github.com/tensorflow/tensorflow/blob/6f692f73cb2043b4a0b0446539cd8c15b3dd9220/tensorflow/core/common_runtime/propagator_state.cc#L878-L891

`CleanupIterations`:
https://github.com/tensorflow/tensorflow/blob/6f692f73cb2043b4a0b0446539cd8c15b3dd9220/tensorflow/core/common_runtime/propagator_state.cc#L774-L799

`iter_state` is deleted on line 778. To solve the "use after free" error in propagator_state.cc, you need to ensure that the memory pointed to by next_iter is not deleted or accessed after it has been deleted.

One approach to achieve this is to modify the code so that the ownership of next_iter is transferred to another object or function, which is responsible for managing its lifetime. For example, you can use a smart pointer such as std::unique_ptr or std::shared_ptr to automatically manage the memory of next_iter.

Another approach is to modify the code to ensure that any functions that may access or modify next_iter after it has been deleted, are modified to prevent this from happening. This may involve adding checks to ensure that the pointer is valid before accessing it, or modifying the control flow of the program to ensure that the pointer is not accessed after it has been deleted.

In either case, it's important to carefully review and test the modified code to ensure that it is correct and does not introduce new bugs. Additionally, it's important to understand the root cause of the error and address any underlying design or architecture issues that may have contributed to the error, to prevent similar issues from arising in the future. can I work on this?  @tiruk007 @PaDarochek  Can you report this (and similar) via OSS VRP? This way, you can also get a bounty if this is a vulnerability. https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md#reporting-vulnerabilities

@bhagirath20 Anyone can send PRs to fix any of the open issues. The first PR that passes review and the merge process is the one that gets merged.
https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md how can I further proceed in this? I have done some changes in code in my repo. and pull request. but it is not visible on TensorFlow main repo pull request page. how can reviewer view and accept my pull request? https://github.com/bhagirath20/tensorflow/pull/1/commits/daa460d88dc256b8b22fd65fe629a400f41289cd . @mihaimaruseac @tiruk007  @mihaimaruseac Reported via OSS VRP. Thanks @PaDarochek .

@bhagirath20 you need to open a PR against TF repo, not against your own repo. Btw, [this PR](https://github.com/bhagirath20/tensorflow/pull/1/files) does not fix use after free. The function calling `CleanupIterations` will still have an ordinary (non unique ptr) pointer that is freed. Also, now the pointer is always deleted that is worse than before. Moreover, the code does not compile. I composed a hello world example for this:

```
#include <iostream>
#include <memory>

void foo(std::unique_ptr<int>& val) {
    std::cout << "val = " << *val << std::endl;
    val.reset();
}

int main() {
    int *a = new int(10);
    auto u = std::unique_ptr<int>(a);
    foo(u);
    std::cout << *a << std::endl;
}
```

    $ clang++ -fsanitize=address main.cpp
    $ ./a.out

```
val = 10
=================================================================
==141988==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000010 at pc 0x5633173797e0 bp 0x7ffffd860df0 sp 0x7ffffd860de8
READ of size 4 at 0x602000000010 thread T0
    #0 0x5633173797df in main (/tmp/a.out+0xde7df) (BuildId: 6ea64e75951ea28d632e046622292c29f16dbef4)
    #1 0x7f302ec37d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #2 0x7f302ec37e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #3 0x5633172b93c4 in _start (/tmp/a.out+0x1e3c4) (BuildId: 6ea64e75951ea28d632e046622292c29f16dbef4)
``` I suppose the fix needs some architectural changes from maintainers familiar with TensorFlow code base. Btw, the text seems to be generated by ChatGPT ;)

![Screenshot from 2023-04-07 18-31-49](https://user-images.githubusercontent.com/22149206/230635883-277ea25c-a959-4301-abd1-d0ee7b7ff8af.png)
<details><summary>Click to expand!</summary> 
 
 ### Issue Type

Bug

### Have you reproduced the bug with TF nightly?

Yes

### Source

source

### Tensorflow Version

tf2.12

### Custom Code

No

### OS Platform and Distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/Compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current Behaviour?

```shell
Pointer `next_iter` from function `PropagatorState::FrameState::IncrementIteration` is passed 
as the 1st parameter into `ActivateLoopInvs` where it is passed as the 1st parameter into 
`AdjustOutstandingOpsLocked`, then inside this function it is passed into `CleanupIterations` 
where it is deleted.

Then in `PropagatorState::FrameState::IncrementIteration` this possibly freed pointer is used 
in `return`-statement.

This behavior was introduced by https://github.com/tensorflow/tensorflow/commit/ae2a0e5c473f2a575767262021c26852d22886f8. 
Before this commit, no `return` was performed on the possibly freed pointer.
```


### Standalone code to reproduce the issue

```shell
Bug was found by Svace static analysis tool.
```


### Relevant log output

_No response_</details>