An issue was discovered in Python 3.11 through 3.11.4. If a path containing '\0' bytes is passed to os.path.normpath(), the path will be truncated unexpectedly at the first '\0' byte. There are plausible cases in which an application would have rejected a filename for security reasons in Python 3.10.x or earlier, but that filename is no longer rejected in Python 3.11.x.
cpe:2.3:a:python:python:*:*:*:*:*:*:*:*
445B042E-9410-42E8-8749-A5EAEF2FF93D
3.11.4
3.11.0
OR
cpe:2.3:a:netapp:active_iq_unified_manager:-:*:*:*:*:windows:*:*
B55E8D50-99B4-47EC-86F9-699B67D473CE
OR
# Bug report

Looks like `posix._path_normpath` has slightly different behaviour to the python implementation of `normpath` defined in `posixpath`, as such `os.path.normpath` behaves differently on Python 3.11 (where `posix._path_normpath` is used if it exists) vs 3.10 on posix systems:

Python 3.10:
```python
>>> import os.path
>>> os.path.normpath('hello\x00world')
'hello\x00world'
>>> os.path.normpath('\x00hello')
'\x00hello'
```

Python 3.11:
```python
>>> import os.path
>>> os.path.normpath('hello\x00world')
'hello'
>>> os.path.normpath('\x00hello')
'.'
```

Obviously filepaths shouldn't have nulls in them, but the above means invalid input to a program could result in the wrong files or directories being used, rather than an error about embedded nulls once the filepaths are actually used for a system call. And I'm guessing the inconsistency between Python3.10 and 3.11, or between the Python and C implementations of `normpath` was not intended in any case.

# Your environment

CPython 3.11.3, running on Arch Linux

Python 3.11.3 (main, Jun  5 2023, 09:32:32) [GCC 13.1.1 20230429] on linux

<!-- gh-linked-prs -->
### Linked PRs
* gh-106816
* gh-107981
* gh-107982
* gh-107983
* gh-108248
* gh-108251
* gh-108252
<!-- /gh-linked-prs -->

os.path.normpath truncates input on null bytes in 3.11, but not 3.10
This is a GitHub Issue
repo:cpython
owner:python
Title : os.path.normpath truncates input on null bytes in 3.11, but not 3.10
Issue date:

--- start body ---
# Bug report

Looks like `posix._path_normpath` has slightly different behaviour to the python implementation of `normpath` defined in `posixpath`, as such `os.path.normpath` behaves differently on Python 3.11 (where `posix._path_normpath` is used if it exists) vs 3.10 on posix systems:

Python 3.10:
```python
>>> import os.path
>>> os.path.normpath('hello\x00world')
'hello\x00world'
>>> os.path.normpath('\x00hello')
'\x00hello'
```

Python 3.11:
```python
>>> import os.path
>>> os.path.normpath('hello\x00world')
'hello'
>>> os.path.normpath('\x00hello')
'.'
```

Obviously filepaths shouldn't have nulls in them, but the above means invalid input to a program could result in the wrong files or directories being used, rather than an error about embedded nulls once the filepaths are actually used for a system call. And I'm guessing the inconsistency between Python3.10 and 3.11, or between the Python and C implementations of `normpath` was not intended in any case.

# Your environment

CPython 3.11.3, running on Arch Linux

Python 3.11.3 (main, Jun  5 2023, 09:32:32) [GCC 13.1.1 20230429] on linux

<!-- gh-linked-prs -->
### Linked PRs
* gh-106816
* gh-107981
* gh-107982
* gh-107983
* gh-108248
* gh-108251
* gh-108252
<!-- /gh-linked-prs -->

--- end body ---

comments :
--- start comments ---

--- end comments ---