Attention is currently required from: fixeria, laforge, pespin.
n0k0 has posted comments on this change by n0k0. ( https://gerrit.osmocom.org/c/libasn1c/+/42890?usp=email )
Change subject: constr_CHOICE: fix always-true bounds check
......................................................................
Patch Set 4:
> this must first and foremost be fixed in upstream asn1c, if it hasn't yet, as libasn1c is merely a shared library version of the asn1c runtime.
Confirmed already fixed upstream, so nothing new is needed there. Current vlm/asn1c master carries the corrected '&&' guard in CHOICE_outmost_tag (skeletons/constr_CHOICE.c:471):
if(present > 0 && present <= td->elements_count) {
The || -> && correctness fix landed upstream back in 2017: commit 494fb707a7cbfc8c563c7125efcf801142e0d0ea ("fix warnings", Lev Walkin, 2017-08-07) changed the guard from '||' to '&&', and the follow-up 63a35237b1704f1491f6a8c40dca6a02b3781e96 (2017-08-10) dropped the redundant '(unsigned)' cast, giving the form master ships today.
libasn1c 0.9.38 is a stale snapshot of the asn1c runtime skeletons that predates that fix, so this change simply backports the already-upstreamed guard into our vendored copy. No upstream asn1c patch is warranted -- upstream is already correct.
(Also amended in patchset 4 to add the missing space after 'if' so gerrit-lint/checkpatch is happy; the '&&' correctness fix is unchanged.)
--
To view, visit https://gerrit.osmocom.org/c/libasn1c/+/42890?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libasn1c
Gerrit-Branch: master
Gerrit-Change-Id: I25e414729f314505bce50bd8107d61bb1e3a44bf
Gerrit-Change-Number: 42890
Gerrit-PatchSet: 4
Gerrit-Owner: n0k0 <osmocom(a)hacky.software>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 12 Aug 2026 12:04:10 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Attention is currently required from: fixeria, laforge, n0k0, pespin.
Hello Jenkins Builder, fixeria, laforge, pespin,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/libasn1c/+/42890?usp=email
to look at the new patch set (#4).
The following approvals got outdated and were removed:
Code-Review+1 by fixeria, Code-Review+1 by laforge, Code-Review+2 by pespin, Verified-1 by Jenkins Builder
Change subject: constr_CHOICE: fix always-true bounds check
......................................................................
constr_CHOICE: fix always-true bounds check
The guard around the td->elements[present - 1] access uses
"present > 0 || present <= td->elements_count". Because every int
satisfies at least one of the two clauses, the condition is always true,
so a present index of 0 or one greater than elements_count indexes the
elements array out of bounds (out of bounds read).
Use "&&" so the access is taken only when present is within
[1, elements_count], matching the equivalent checks already used in
CHOICE_constraint() and the print/compare helpers in this file.
Change-Id: I25e414729f314505bce50bd8107d61bb1e3a44bf
---
M src/constr_CHOICE.c
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/libasn1c refs/changes/90/42890/4
--
To view, visit https://gerrit.osmocom.org/c/libasn1c/+/42890?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newpatchset
Gerrit-Project: libasn1c
Gerrit-Branch: master
Gerrit-Change-Id: I25e414729f314505bce50bd8107d61bb1e3a44bf
Gerrit-Change-Number: 42890
Gerrit-PatchSet: 4
Gerrit-Owner: n0k0 <osmocom(a)hacky.software>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: n0k0 <osmocom(a)hacky.software>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Attention is currently required from: fixeria, laforge, n0k0, pespin.
Hello Jenkins Builder, fixeria, laforge, pespin,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/libsmpp34/+/42889?usp=email
to look at the new patch set (#4).
The following approvals got outdated and were removed:
Code-Review+1 by laforge, Code-Review+1 by pespin, Code-Review+2 by fixeria, Verified-1 by Jenkins Builder
Change subject: smpp34_unpack: bound C_OCTET scan with strnlen()
......................................................................
smpp34_unpack: bound C_OCTET scan with strnlen()
The C_OCTET macro runs strlen() on the attacker-controlled wire buffer
before any bounds check. SMPP PDUs are decoded straight out of a buffer
sized exactly to the wire command_length with no trailing NUL, so a
C-Octet-String field that runs to the end of the buffer without a
terminator makes strlen() read past the end of the allocation (out of
bounds heap read), and the post-hoc "lenval > left" check runs only
after the over-read has already happened.
Scan with strnlen(aux, left) so the read can never go past the remaining
buffer; if no terminator is found within 'left' bytes, lenval becomes
left + 1 and the existing length check rejects the PDU.
This issue has been assigned the CVE candidate identifier
CAN-2026-2051038.
Change-Id: Ie87b16cad0dbdc8ea8397c1b065b8545f23ac814
---
M src/smpp34_unpack.c
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/libsmpp34 refs/changes/89/42889/4
--
To view, visit https://gerrit.osmocom.org/c/libsmpp34/+/42889?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newpatchset
Gerrit-Project: libsmpp34
Gerrit-Branch: master
Gerrit-Change-Id: Ie87b16cad0dbdc8ea8397c1b065b8545f23ac814
Gerrit-Change-Number: 42889
Gerrit-PatchSet: 4
Gerrit-Owner: n0k0 <osmocom(a)hacky.software>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: n0k0 <osmocom(a)hacky.software>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Attention is currently required from: n0k0.
Jenkins Builder has posted comments on this change by n0k0. ( https://gerrit.osmocom.org/c/libsmpp34/+/42889?usp=email )
Change subject: smpp34_unpack: bound C_OCTET scan with strnlen()
......................................................................
Patch Set 3:
(4 comments)
File src/smpp34_unpack.c:
Robot Comment from checkpatch (run ID ):
https://gerrit.osmocom.org/c/libsmpp34/+/42889/comment/3b97a1da_50a2fe14?us… :
PS3, Line 130: lenval = strnlen( (char*) aux, left ) + 1;\
please, no spaces at the start of a line
Robot Comment from checkpatch (run ID ):
https://gerrit.osmocom.org/c/libsmpp34/+/42889/comment/ccecbba5_d7b99fc2?us… :
PS3, Line 130: lenval = strnlen( (char*) aux, left ) + 1;\
"(foo*)" should be "(foo *)"
Robot Comment from checkpatch (run ID ):
https://gerrit.osmocom.org/c/libsmpp34/+/42889/comment/0499e315_db184520?us… :
PS3, Line 130: lenval = strnlen( (char*) aux, left ) + 1;\
space prohibited after that open parenthesis '('
Robot Comment from checkpatch (run ID ):
https://gerrit.osmocom.org/c/libsmpp34/+/42889/comment/8fc592ab_6a081a5f?us… :
PS3, Line 130: lenval = strnlen( (char*) aux, left ) + 1;\
space prohibited before that close parenthesis ')'
--
To view, visit https://gerrit.osmocom.org/c/libsmpp34/+/42889?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libsmpp34
Gerrit-Branch: master
Gerrit-Change-Id: Ie87b16cad0dbdc8ea8397c1b065b8545f23ac814
Gerrit-Change-Number: 42889
Gerrit-PatchSet: 3
Gerrit-Owner: n0k0 <osmocom(a)hacky.software>
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: Jenkins Builder
Gerrit-Attention: n0k0 <osmocom(a)hacky.software>
Gerrit-Comment-Date: Wed, 12 Aug 2026 11:42:54 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Attention is currently required from: dexter, jolly.
laforge has posted comments on this change by jolly. ( https://gerrit.osmocom.org/c/onomondo-ipa/+/43202?usp=email )
Change subject: Introduce 'operation' option to main file
......................................................................
Patch Set 2: -Code-Review
(1 comment)
File src/ipa/main.c:
https://gerrit.osmocom.org/c/onomondo-ipa/+/43202/comment/8d3938b5_3f7acb32… :
PS2, Line 193: break;
I think this change is only half-done.
Let's please also introduce an enum for the operation, and have one global variable with that enum type, initialized to the default mode. The main body after the getopt-while-loop then consists mainly of a single switch statement based on the mode.
--
To view, visit https://gerrit.osmocom.org/c/onomondo-ipa/+/43202?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: onomondo-ipa
Gerrit-Branch: master
Gerrit-Change-Id: I6b960f840820990de40fb07332669ddbfcdf1e7d
Gerrit-Change-Number: 43202
Gerrit-PatchSet: 2
Gerrit-Owner: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: jolly <andreas(a)eversberg.eu>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 12 Aug 2026 11:40:04 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Attention is currently required from: laforge, lynxis lazus.
dexter has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/simtrace2/+/43185?usp=email )
Change subject: Add osmo_apdu_segment_in2() to ensure correct parsing of GP GET DATA
......................................................................
Patch Set 3: Code-Review+1
(10 comments)
Patchset:
PS3:
I have looked through your patch. Unfortunately I do not have the big picture, but the problem you describe and the solution appears to make sense.
As far as I understand the problem is that the information about the original APDU case gets lost and this later causes problems when forwarding it. That is why you transfer the prev_ac->apdu_case to ac->apdu_case.
Where I am a bit lost is to understand the difference between ETSI TS 102 221, Table 7.1 and GlobalPlatform A.1. They both apparently perform the re-send in the same manner. Maybe this corner case is more generic than originally assumed. You may also have a look [1], maybe this is helpful.
[1] https://gitea.osmocom.org/sim-card/pysim/src/branch/master/pySim/transport/…
Commit Message:
https://gerrit.osmocom.org/c/simtrace2/+/43185/comment/6e023419_0d59277c?us… :
PS3, Line 9: osmo_apdu_segment_in() don't have the context of the previous APDU,
don't => does not
https://gerrit.osmocom.org/c/simtrace2/+/43185/comment/b8040acd_06f148ee?us… :
PS3, Line 12: GP GET DATA defines the Le field as 0x00 which is used to detect if this
this => it
https://gerrit.osmocom.org/c/simtrace2/+/43185/comment/0606454e_310fc93b?us… :
PS3, Line 17: instead of a case 2 with Le != 0.
I am having difficulties to understand this description. After responding we cannot go back and manipulated the Le field, we would have to go back in time. Which we cannot. Do you mean prev_ac with that. Or do you wanted to write ".. the following GP GET DATA ..."?
File host/lib/apdu_dispatch.c:
https://gerrit.osmocom.org/c/simtrace2/+/43185/comment/177859c7_811fa7c0?us… :
PS3, Line 86: * \param prev_ac Previous APDU context across successive calls
ac and prev_ac are [inout], right? (its probably not necessary to explicitly mark inout parameter in doxygen...)
https://gerrit.osmocom.org/c/simtrace2/+/43185/comment/00bf6a02_a1d0661d?us… :
PS3, Line 120: ac->hdr.cla & 0x80 && /* check for GP */
In GlobalPlatform Card Specification, section 11.3.2 they list more possible CLA bytes. Those are probably not relevant for our usecase. I also have only seen 0x80 so far.
File host/tests/apdu_dispatch/apdu_dispatch_test.c:
https://gerrit.osmocom.org/c/simtrace2/+/43185/comment/5ebb424a_830ea41f?us… :
PS3, Line 18: memset(&prev_ac, 0, sizeof(prev_ac)); \
prev_ac only appears in the memset and nowhere else, is this line needed in this macro?
https://gerrit.osmocom.org/c/simtrace2/+/43185/comment/c6612c0b_67103fa9?us… :
PS3, Line 22: printf("%d (actual) != %d (intended)\n", rc, exp_rc);\
I think (expected) is more accurate. The variable is also called "exp_rc".
https://gerrit.osmocom.org/c/simtrace2/+/43185/comment/cc45f40d_9d1f2fc4?us… :
PS3, Line 55: rc = osmo_apdu_segment_in2(&ac, &prev_ac, get_data_c2_ca, ARRAY_SIZE(get_data_c2_ca), 1);
The last parameter of osmo_apdu_segment_in2 is a bool. Maybe it is better to pass true instead of 1 then. Its the same, but easier to read.
https://gerrit.osmocom.org/c/simtrace2/+/43185/comment/30c364ec_cb77aaaf?us… :
PS3, Line 70: OSMO_ASSERT(rc == APDU_ACT_TX_CAPDU_TO_CARD);
I wonder if it would make sense to inspect the contents of ac and prev_ac after osmo_apdu_segment_in2 was called.
--
To view, visit https://gerrit.osmocom.org/c/simtrace2/+/43185?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: simtrace2
Gerrit-Branch: master
Gerrit-Change-Id: Ie238662e7e6a10dd4283ede0c8d8d73bc375c247
Gerrit-Change-Number: 43185
Gerrit-PatchSet: 3
Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Comment-Date: Wed, 12 Aug 2026 11:03:55 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes