lynxis lazus has uploaded a new patch set (#2). ( https://gerrit.osmocom.org/c/libosmocore/+/43178?usp=email )
Change subject: RFC: sim/class_tables: add a size attribute
......................................................................
RFC: sim/class_tables: add a size attribute
osim_determine_apdu_case() doesn't know the size of the APDU,
this may result in reading invalid data outside the APDU.
Warning: this is an API breakage!
Instead adding a second function osim_determine_apdu_case_size()
could allow it. However because the class_tables.h also defines
the internal struct with the helper functions, which in turn has the same problem.
Change-Id: Iee50063399a0c3b29594e737f44aaa125fd06a2e
---
M include/osmocom/sim/class_tables.h
M src/sim/class_tables.c
M tests/sim/sim_test.c
3 files changed, 30 insertions(+), 16 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/78/43178/2
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/43178?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newpatchset
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Iee50063399a0c3b29594e737f44aaa125fd06a2e
Gerrit-Change-Number: 43178
Gerrit-PatchSet: 2
Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu>
n0k0 has uploaded a new patch set (#3). ( https://gerrit.osmocom.org/c/libsmpp34/+/42889?usp=email )
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/3
--
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: 3
Gerrit-Owner: n0k0 <osmocom(a)hacky.software>
n0k0 has uploaded a new patch set (#3). ( https://gerrit.osmocom.org/c/osmo-iuh/+/42887?usp=email )
Change subject: iu_client: reject oversized RANAP NAS-PDU
......................................................................
iu_client: reject oversized RANAP NAS-PDU
The connection-oriented RANAP handlers ranap_handle_co_initial_ue() and
ranap_handle_co_dt() copy the attacker-controlled NAS-PDU into a msgb
allocated with a fixed 256 bytes. RANAP NAS-PDU is an unconstrained
OCTET STRING, so the APER decoder accepts an arbitrarily large PDU; when
nas_pdu.size exceeds the msgb tailroom, msgb_put() hits MSGB_ABORT and
osmo_panic()s the process (MSGB_DEBUG is compiled in unconditionally),
which a femtocell (HNB) peer can use to crash osmo-hnbgw / osmo-hnodeb
by sending an InitialUE or DirectTransfer with a NAS-PDU > 256 bytes.
Validate nas_pdu.size against the msgb tailroom and drop the message
gracefully instead of panicking.
This issue has been assigned the CVE candidate identifier
CAN-2026-2051037.
Change-Id: I7dbce926477f9842cd466d46cda836638f04011f
---
M src/iu_client.c
1 file changed, 12 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-iuh refs/changes/87/42887/3
--
To view, visit https://gerrit.osmocom.org/c/osmo-iuh/+/42887?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newpatchset
Gerrit-Project: osmo-iuh
Gerrit-Branch: master
Gerrit-Change-Id: I7dbce926477f9842cd466d46cda836638f04011f
Gerrit-Change-Number: 42887
Gerrit-PatchSet: 3
Gerrit-Owner: n0k0 <osmocom(a)hacky.software>
n0k0 has uploaded a new patch set (#3). ( https://gerrit.osmocom.org/c/osmo-bsc/+/42886?usp=email )
Change subject: ipaccess-proxy: reject oversized IPA frame length
......................................................................
ipaccess-proxy: reject oversized IPA frame length
ipaccess_proxy_read_msg() reads the 16-bit IPA frame length from the
wire header and passes it straight as the recv() count into a msgb that
was allocated with a fixed PROXY_ALLOC_SIZE (1200) bytes, without ever
checking it against the buffer tailroom. A peer that advertises a body
length larger than the remaining buffer space makes recv() write past
the end of the heap allocation (heap buffer overflow).
Reject frames whose advertised length exceeds the msgb tailroom, the
same way the other IPA read paths bound the read to msgb_tailroom().
This issue has been assigned the CVE candidate identifier
CAN-2026-2051036.
Change-Id: I05137e114eaa99ff0e85eecccf7645c90945214f
---
M src/ipaccess/ipaccess-proxy.c
1 file changed, 6 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bsc refs/changes/86/42886/3
--
To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/42886?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newpatchset
Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: I05137e114eaa99ff0e85eecccf7645c90945214f
Gerrit-Change-Number: 42886
Gerrit-PatchSet: 3
Gerrit-Owner: n0k0 <osmocom(a)hacky.software>
n0k0 has uploaded a new patch set (#3). ( https://gerrit.osmocom.org/c/osmo-ggsn/+/42885?usp=email )
Change subject: gtp: fix OOB write in PDP ctx GSN-Address decode
......................................................................
gtp: fix OOB write in PDP ctx GSN-Address decode
gtp_decode_pdp_ctx() takes the GSN-Address sub-field lengths of a PDP
Context IE (gsnrc / gsnru, the GGSN control- and user-plane addresses)
straight from the wire and memcpy()s that many bytes into the fixed
16-byte 'struct ul16_t' v[] array, with no check against the destination
size. decode_pdp_ctx_len_check() only validates the declared lengths
against the *input* buffer, never against the destination capacity, so a
wire length of 17..255 overflows the 16-byte field by up to 239 bytes,
clobbering adjacent struct pdp_t state.
The PDP Context IE is carried in SGSN Context Response / Forward
Relocation messages exchanged between peer GSNs over Gn/Gp, so a
malicious or spoofed peer GSN can trigger this. The same libgtp decoder
is linked by osmo-sgsn, so it is affected as well.
A GSN address is 4 (IPv4) or 16 (IPv6) bytes, so reject any length that
does not fit the destination before copying.
This issue has been assigned the CVE candidate identifier
CAN-2026-2051035.
Change-Id: Id69e82fe1a16933d8c6b9c848a2ede29f7920d98
---
M gtp/gtp.c
1 file changed, 12 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ggsn refs/changes/85/42885/3
--
To view, visit https://gerrit.osmocom.org/c/osmo-ggsn/+/42885?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newpatchset
Gerrit-Project: osmo-ggsn
Gerrit-Branch: master
Gerrit-Change-Id: Id69e82fe1a16933d8c6b9c848a2ede29f7920d98
Gerrit-Change-Number: 42885
Gerrit-PatchSet: 3
Gerrit-Owner: n0k0 <osmocom(a)hacky.software>
Attention is currently required from: dexter, laforge.
Hoernchen has posted comments on this change by Hoernchen. ( https://gerrit.osmocom.org/c/pysim/+/43172?usp=email )
Change subject: GP: LOAD/STORE DATA chunk size from SCP overhead
......................................................................
Patch Set 2:
(2 comments)
File pySim/global_platform/__init__.py:
https://gerrit.osmocom.org/c/pysim/+/43172/comment/b9400ec7_a4658458?usp=em… :
PS1, Line 871: load_parser.add_argument('--chunk-len', type=auto_uint8, default=None,
> (cosmetic, no blocker) as far as I know the default is always None, no need to set it explicitly.
I wanted to make sure that auto uint8 as None is a deliberate default, not accidental implicit None.
File pySim/global_platform/scp.py:
https://gerrit.osmocom.org/c/pysim/+/43172/comment/1fba4d61_33286b2f?usp=em… :
PS1, Line 195: # is one byte less than the largest block-size multiple within 255 - mac_len.
> Would be nice to have a spec reference here (for the interested reader).
there you go, it's just standard aes...
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/43172?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: Ic208f3959a38896f64fb6ccefb24cc360a3ac3a2
Gerrit-Change-Number: 43172
Gerrit-PatchSet: 2
Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>
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: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 07 Aug 2026 11:51:13 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: dexter <pmaier(a)sysmocom.de>
Attention is currently required from: Hoernchen, dexter, laforge.
Hello Jenkins Builder, dexter, laforge,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/pysim/+/43172?usp=email
to look at the new patch set (#2).
The following approvals got outdated and were removed:
Code-Review+1 by laforge, Code-Review+2 by dexter, Verified+1 by Jenkins Builder, Verified+1 by dexter
The change is no longer submittable: Code-Review and Verified are unsatisfied now.
Change subject: GP: LOAD/STORE DATA chunk size from SCP overhead
......................................................................
GP: LOAD/STORE DATA chunk size from SCP overhead
SCP.overhead was so far set at construction time (SCP02: 8, SCP03:
s_mode), so the C-MAC length only.
Unfortunately sec lvl >= 3 pads the data field to the cipher block size
before encryption, so the real worst-case overhead is larger,
scc.max_cmd_len (255 - overhead) was too big, and ADF_SD.load()
used a hardcoded chunk_len=240.
Real world issue with a 286 byte CAP + SCP02 + sec lvl 3:
- 240-byte LOAD block is padded to 248,
- encrypted
- gets 8 byte C-MAC appended
-> Lc = 256
That dies with a weird "ValueError: bytes must be in range(0, 256)".
The only "fix" for that was to downgrade the seclevel.
STORE DATA has the same overflow with large max_cmd_len
(247 + padding + MAC = 256 as well).
Therefore the overhead must be properly calculated from the sec level.
While at it adjust the error in case I missed something to get a more
useful ValueError.
Change-Id: Ic208f3959a38896f64fb6ccefb24cc360a3ac3a2
---
M pySim/global_platform/__init__.py
M pySim/global_platform/scp.py
M tests/unittests/test_globalplatform.py
3 files changed, 224 insertions(+), 12 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/pysim refs/changes/72/43172/2
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/43172?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newpatchset
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: Ic208f3959a38896f64fb6ccefb24cc360a3ac3a2
Gerrit-Change-Number: 43172
Gerrit-PatchSet: 2
Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Attention is currently required from: Hoernchen.
dexter has posted comments on this change by Hoernchen. ( https://gerrit.osmocom.org/c/python/pyosmocom/+/43171?usp=email )
Change subject: tlv: preserve the comprehension bit
......................................................................
Patch Set 1: Code-Review+1
(5 comments)
Patchset:
PS1:
I have looked through your patch and I think it is plausible, however it introduces a state that other TLV classes don't have. Maybe this needs some explanation.
Commit Message:
https://gerrit.osmocom.org/c/python/pyosmocom/+/43171/comment/fec56f4a_fb90… :
PS1, Line 35: instead of setting the flag, currently tag=0x8123 -> 0x81a3.
I would split this in a separate patch (only if you think this would speed things up, as I think this part would be ready at least.)
File src/osmocom/tlv.py:
https://gerrit.osmocom.org/c/python/pyosmocom/+/43171/comment/4228f038_52c1… :
PS1, Line 658: # True/False: as received
Maybe it makes sense to explain this property in greater detail? This is an additional state an API user would expect right away. I understand this as a state that flips to the state of the last parsed CR bit when from_tlv() has been used. This basically means that when I have used from_tlv() once, the API user cannot rely on the CR bit set as originally defined.
This is probably a corner case as the IE objects are usually short lived and probably not wildly mixed. Decode, change something, Re-Encode is probably the most exciting usecase to expect but I still think we should have an explanatory comment here.
File tests/test_tlv.py:
https://gerrit.osmocom.org/c/python/pyosmocom/+/43171/comment/873ef7ec_0ebd… :
PS1, Line 83:
I would add a comment that explains that the first vector has the CR bit set, but the second has not. And both must come out the same when they are decoded and re-encoded.
https://gerrit.osmocom.org/c/python/pyosmocom/+/43171/comment/81a1304c_23ed… :
PS1, Line 86: ie.from_tlv(encoded)
maybe add an assert that checks that ie.comprension has changed state as expected?
--
To view, visit https://gerrit.osmocom.org/c/python/pyosmocom/+/43171?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: python/pyosmocom
Gerrit-Branch: master
Gerrit-Change-Id: Ifae37785e2a586d9130d154bc7244f35fa6f2a55
Gerrit-Change-Number: 43171
Gerrit-PatchSet: 1
Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 07 Aug 2026 11:30:55 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes