感谢提交Issue！关于Issue的交互操作，请访问OpenHarmony社区支持命令清单。如果有问题，请联系 [@byx0010](https://gitcode.com/byx0010) [@chen-botong](https://gitcode.com/chen-botong) [@jzy_123](https://gitcode.com/jzy_123) [@zhang-haowen123](https://gitcode.com/zhang-haowen123) [@michael4096](https://gitcode.com/michael4096) [@jeosif](https://gitcode.com/jeosif) [@liangliang_ma](https://gitcode.com/liangliang_ma) [@firstsummer](https://gitcode.com/firstsummer) [@songzhengteng](https://gitcode.com/songzhengteng) [@tanyanying](https://gitcode.com/tanyanying) 。如果需要调整订阅PR、Issue的变更状态，请访问链接。
Thanks for submitting the issue. For more commands, please visit OpenHarmony Command List. If you have any questions, please refer to committer gitcode for help. If you need to change the subscription of a Pull Request or Issue, please visit the link.
感谢对OpenHarmony社区的支持与关注，欢迎反馈缺陷。
发生了什么问题？
部分 IPC 处理函数对 pkgName 做了 strnlen(pkgName, PKG_NAME_SIZE_MAX) 长度上界校验,另一些只判 nullptr(或 nullptr+strlen==0),校验不一致。未做上界校验的入口允许超长 pkgName 越过 IPC 边界,而服务层大量使用定长 char pkgNamePKG_NAME_SIZE_MAX缓冲,存在潜在溢出风险。本次统一在 IPC 边界补齐长度上界,做纵深防御。
期望行为是什么？
在 17 处 pkgName 读取点追加 strnlen(pkgName, PKG_NAME_SIZE_MAX) >= PKG_NAME_SIZE_MAX(或宏式 && strnlen(...) < PKG_NAME_SIZE_MAX)校验,沿用各函数既有判空 idiom 与返回码,正常路径(合法 pkgName)行为不变。
如何复现该缺陷
NA
其他补充信息
版本或分支信息